You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We investigate how the NHS fork of the Kit has been built. What features there are and why. Also considering how these features might be used by other departments i.e. common functionality.
Linked to #2166 and should be worked on simultaneously.
Why
So we understand how we should design the user experience of creating prototypes using different plugins to GOV.UK Frontend
Who
Developers
Designers
Done when
Scope of the investigation is discussed and decided as a team
Talk to the NHS team about their fork of the Kit - particularly is there anything that doesn't work/isn't useful?
All the features built into the NHS fork of the Kit are considered
How this could be used by non-NHS teams as common functionality is considered
Findings and an internal proof of concept are shared and discussed with the team
The text was updated successfully, but these errors were encountered:
Here's the approach we used when building the spike and it's what I'd recommend for the solution when we build it. I'm using the term variants to describe plugins that specify how a newly created kit should function.
It needs to be democratic in the way that plugins are democratic - anyone should be able to create a variant without it being centrally approved.
The Prototype Kit itself is the vanilla (default) variant, but it is a variant just like any other.
Variants can build upon other variant - particularly relevant for people building on top of the vanilla kit.
Variants come from a config file similar to the govuk-prototype-kit.config.json in the root of NPM modules.
We need to support specific versions in the same way as NPM does.
A variant should be able to specify:
Starter files
Manipulation of starter files
Pre-installed plugins
List of available plugins
So that means that people can create the following variants:
HMRC
Just a normal kit but with hmrc-frontend pre-installed.
Files inside the prototype-kit-starter-files directory would be copied after the core kit files, that means they can just override individual files like layout.html.
postCreateScripts would run afterwards - e.g. to update the package.json.
That's the plan I have, the importance of __INHERIT__ is that the variant creator gets to decide whether they run theirs before or after ours or not at all. The inheritFrom property brings over everything from our variant file by default, but if it's overridden with something that doesn't define INHERIT then our one isn't used.
For example: Both NHS and HMRC examples above inherit the git, if they didn't want that they can override it.
What
We investigate how the NHS fork of the Kit has been built. What features there are and why. Also considering how these features might be used by other departments i.e. common functionality.
Linked to #2166 and should be worked on simultaneously.
Why
So we understand how we should design the user experience of creating prototypes using different plugins to GOV.UK Frontend
Who
Done when
The text was updated successfully, but these errors were encountered: