Open adamsilver opened 5 years ago
Thanks @adamsilver, really useful to get feedback on Extensions, we want to get it right before launching it.
Option A is currently our preferred approach as there are problems with B and C:
B: this requires the end user to make changes to server.js - we want the experience for end users to be as simple as possible - hopefully just npm install [extension name]
C: we can't allow extensions to use /assets
- we need to namespace them in some predictable way so files can never clash. If two extensions did what's proposed in option C, and had the same file name in each, only one of them would work.
Currently, we (authors of packages) are not told how to develop the packages.
So for example, HMCTS Frontend doesn't (yet) namespace the paths to the macros. Similarly, the path to the assets are specified as /assets
. It just so happens that we follow the same good practice as GOV.UK Frontend by making that path configurable with a SASS variable—but technically we don't have to and nobody makes us do so.
So while namespacing etc is a good idea, it's not enforced upon us.
To note, I've not come across any problems so far in the last 10 months or so any conflicts with HMCTS Frontend and GOV.UK Frontend having the same asset path.
The beauty, as I see it, with the config file, is that all package authors have to do is include and configure just one single file and the rest is magically handled by the prototype kit. But currently, there is no way to configure the asset path to which the assets are mounted within the config, leading us to have to use option A.
If the config did allow the asset mount path to be configured, the problem would be solved without forcing the package authors to do extra works in the source code beyond the config file. My point is that the config file should be enough on its own to accommodate the varying nature of how packages could be built.
The alternative to this is that the package becomes “contaminated” (strong word) with bits of code that exist just for the prototype kit extension stuff to work.
What do you think about us exploring option C together?
If the config did allow the asset mount path to be configured
sure, it's a good direction!
If you could define it inside config that would be nice, but I’m not sure how we could communicate that path back to the scss
Maybe the extensions shouldn't define their own assets path like hmrc-frontend does, maybe the kit should. The kit could say, ok, you’re hmrc-frontend
, your assets will be mounted at /extension-assets/hmrc-frontend
.
Problem is, in their scss they would have something like this:
background-image: url("#{$hmrc-assets-path}icon-chevron-left.svg");
We’d need to know the variable name is $hmrc-assets-path
, or whatever it was in other extensions.
Maybe we could set a convention - tell people to use the variable $assets-path
?
Maybe extensions could tell us what that variable name is, in the config?
asset-path-variable: "hmrc-assets-path"
I don't think we should enforce a convention like that.
I was thinking that if I setup the HMCTS Frontend asset path to /hmcts-assets
(by hardcoding or by using a SASS var) then I will setup the config file like this:
{ assets: [{ mountPath: '/hmcts-assets
, ... }] }`
That cool?
@nataliecarey for your consideration
we'll see if this comes up in our upcoming user research
Currently, I have specified the following config file for HMCTS Frontend:
{ "assets": ["/assets/images"] }
This alone is not enough for the kit to be able to reference the static assets and load them in the browser.
There are three ways to solve this that I’m aware of.
Option A
(This is what HMRC Frontend does)
Option B
(This is what I’ve currently opted for)
app.use('/assets', express.static(path.join(__dirname, 'node_modules', '@hmcts', 'frontend', 'assets')))
Option C
Change the way the config file works so that not only can you specify the location of the assets but also where they should be mounted
{ "assets": [{ mountPath: “/assets”, path: “/assets/images" }]
Or something like that.
I strongly recommend C because I don’t believe packages should have to change anything in their source code to make the prototype kit work beyond the config file.