Rename exported JavaScript modules to include component name

[vanitabarrett]

Closes #1836

What

Change the window global and UMD export name for component JavaScript to include the component name, for example: GOVUKFrontend.CharacterCount.

The way this PR currently stands, this new naming applies only to component JavaScript files - not toall.js, common.js or any vendor/polyfills. Because all.js already exports multiple modules, we can keep the original naming of GOVUKFrontend and modules will already be automatically nested underneath, e.g: window.GOVUKFrontend.initAll(). If the new naming system was also applied to all.js, you would end up having to call window.GOVUKFrontend.All.initAll().

This means that if a user imports a specific component JavaScript (e.g: character-count) and thenall.js - all.js will overwrite any existing modules attached to window.GOVUKFrontend. This feels like an unlikely scenario, but I'm not sure I know enough about how users are importing our JavaScript to know if applying this change only to component JavaScript is likely to cause problems - welcome any thoughts/insights on this.

Why

When importing individual scripts, each one was attached to window.GOVUKFrontend. This meant that if you imported (for example) the accordion and then imported the button JavaScript, one overwrote the other so that only the button JavaScript would be attached to window.GOVUKFrontend.

Breaking Changes

Again - I welcome any thoughts/insights on this as I'm not 100% confident I know enough about how users are using our JavaScript to account for all changes that might need to be made

If a user is importing all our JavaScript, I don't think they'll need to make any changes.

If a user is importing individual component JavaScript, then they will need to switch any calls to window.GOVUKFrontend to be to window.GOVUKFrontend.[ComponentName]

[lfdebrux]

I'm not sure I understand what is going on in the first commit... would you mind expanding a bit on why you're making the change and what it means? 😅

[vanitabarrett]

@lfdebrux I'll try to explain it more here, let me know if it's any more helpful! If not, happy to jump on a call to chat about it.

The current gulp task as it is on main sets up an array of JavaScript files, and gulp uses streams to pass that data through the rest of the transformations (rollup, uglify etc). We need to make a change to the rollup config so that the name contains the component name and isn't just "GOVUKFrontend" for every single module. In order to do that, we need some way of accessing what current file we're "on"/"processing" so we can pull out the relevant component name.

As far as I can tell, there's no easy way of doing this with the current set-up as gulp streams mean you don't get that concept of 'this is the thing that's currently being processed'. I might be wrong about that, welcome to other suggestions!

So in order to get more "control" over knowing what file is currently being processed, I've introduced a forEach loop which loops through every JavaScript file and passes that through the same gulp process as before - but this time, gulp is being passed one file at a time rather than an array of files at the start. That means we know what file we're on and we have access to the pathname and filename etc.

[lfdebrux]

@lfdebrux I'll try to explain it more here, let me know if it's any more helpful! If not, happy to jump on a call to chat about it.

The current gulp task as it is on main sets up an array of JavaScript files, and gulp uses streams to pass that data through the rest of the transformations (rollup, uglify etc). We need to make a change to the rollup config so that the name contains the component name and isn't just "GOVUKFrontend" for every single module. In order to do that, we need some way of accessing what current file we're "on"/"processing" so we can pull out the relevant component name.

As far as I can tell, there's no easy way of doing this with the current set-up as gulp streams mean you don't get that concept of 'this is the thing that's currently being processed'. I might be wrong about that, welcome to other suggestions!

So in order to get more "control" over knowing what file is currently being processed, I've introduced a forEach loop which loops through every JavaScript file and passes that through the same gulp process as before - but this time, gulp is being passed one file at a time rather than an array of files at the start. That means we know what file we're on and we have access to the pathname and filename etc.

Ah, I get it now, thank you!

[36degrees]

It'd be nice to have tests to cover at least some of this, but no idea how to make that happen…

Maybe we could add a test to after-build-package.test.js that looks at the component JS and asserts something about the exported name?

[36degrees]

Looks good to me, just one suggestion re how we import the componentNameToJavaScriptModuleName method.

[36degrees]

Looks good to me.

Have manually run the build:dist and build:package tasks and the output looks like what I'd expect – although it looks like using the dist version of the JS the modules are not attached to GOVUKFrontend, but I guess that's expected? It doesn't appear to be a change from the existing behaviour, anyway.

[EoinShaughnessy]

@vanitabarrett Looks great! Just a few tiny comments.

[EoinShaughnessy]

@vanitabarrett Looks good!

[vanitabarrett]

Thanks for your reviews @EoinShaughnessy and @36degrees ! I'm going to hold off merging this for a bit as I've asked @alex-ju to test this change in the GOV.UK Publishing Components to double check it works as expected.

[alex-ju]

Many thanks for the work on this, Vanita! 🙌
Tested this change in alphagov/govuk_publishing_components#2457 and it works as expected.
This approach – with window.GOVUKFrontend.initAll() (when importing everything) and window.GOVUKFrontend.Button(element).init() (for individual imports) – is what I would expect as a consumer.