Compile ES modules using Rollup

[colinrotherham]

This PR uses Rollup to compile (not copy) ES modules into ./package/govuk-esm

It adds on to recent "Build tasks" work to unblock:

• Include the govuk-frontend version number in CSS and JS files #3318

[colinrotherham]

Notice the glob pattern has the suffix **/ removed

Rollup will automatically find child import modules for us from top-level entry scripts like:

./src/govuk/all.mjs
./src/govuk/common.mjs
./src/govuk/i18n.mjs

[colinrotherham]

Regarding the "experimental" option name, I've taken a closer look and we're good to go.

Since we're currently pinned on Rollup v0.59.4 (for IE8 { legacy: true }) we get stable module support. But until the Rollup v1.0.0 release there were few missing features to be aware of:

1. No dynamic import()
2. No multiple input named entries in watch mode
3. No chunk optimisation
4. No tree shaking

We don't actually need these (yet) as we currently only copy our *.mjs files between directories.

I've added some background info for context:

Rollup v0.57.0

The option { experimentalPreserveModules } was added in Rollup v0.57.0

This takes us from 15 March 2018 to the last IE8 release in 28 May 2018:

rollup@0.57.0
rollup@0.57.1
rollup@0.58.0
rollup@0.58.1
rollup@0.58.2
rollup@0.59.0
rollup@0.59.1
rollup@0.59.2
rollup@0.59.3
rollup@0.59.4

Rollup v0.58.0

It was stabilised in Rollup v0.58.0 with some notable PRs:

Hoisting of deep imports for performance
(e.g. Polyfills moved into all.mjs)
rollup/rollup#2073

Fixes for "single file" builds like ours
rollup/rollup#2123

Warnings removed for tree-shaken imports (that were exported)
rollup/rollup#2124

Rollup v0.59.0

With another fix in Rollup v0.59.0

Fixes for file paths in source maps
rollup/rollup#2161

Rollup v1.0.0

The option was renamed to { preserveModules } in Rollup v1.0.0

[romaricpascal]

To track what was mentioned in the dev catch-up, the hoisting of deep imports may have impacts on tree-shaking, which need looking into.

In our current package, import {Accordion} from 'govuk-frontend' will only bring the polyfills necessary for the Accordion.

However with the polyfills of all components being hoisted when building all.mjs, it's likely polyfills that the Accordion doesn't need will end up in the final bundle (especially as our polyfills are not pure), so we'll need to check what happens there.

[colinrotherham]

@romaricpascal That's a great point

Thankfully the hoisted imports in all.mjs (from this PR) continue to be tree shaken away 🎉

Below is some testing from our webpack example using only { Button } via import/require

Bundling via import from copied files

File sizes for main.min.js with webpack resolving package/govuk-esm/* copied ES modules

14KB — Button polyfills only

import { Button } from 'govuk-frontend'

import { Button } from 'govuk-frontend/govuk-esm/all.mjs'

import Button from 'govuk-frontend/govuk-esm/components/button/button.mjs'

Bundling via import from Rollup es output

File sizes for main.min.js with webpack resolving package/govuk-esm/* compiled ES modules

14KB — Button polyfills only

import { Button } from 'govuk-frontend'

import { Button } from 'govuk-frontend/govuk-esm/all.mjs'

import Button from 'govuk-frontend/govuk-esm/components/button/button.mjs'

Bundling via require() from Rollup umd output

File sizes for main.min.js with webpack resolving package/govuk/* compiled UMD modules

50KB — All polyfills included

const { Button } = require('govuk-frontend')

const { Button } = require('govuk-frontend/govuk/all.js')

12KB — Button polyfills only

const Button = require('govuk-frontend/govuk/components/button/button.js')

[colinrotherham]

I've completed testing in Rollup with npm link on a local build of GOV.UK Frontend

Good news, JavaScript output is identical

Source map content appears to be the Rollup-transformed ES module code (with semicolons inserted etc) but this is likely GOV.UK Design System @rollup/* plugins needing an "input source map" config to find the original sources

[36degrees]

This function seems to be doing 2 different jobs in two separate code paths – would it make sense to split it into two functions (one for generating a bundle and one that preserves modules) and decide which one to call in the compile function instead?

[colinrotherham]

Yeah could do. Only reason I didn't is that we'll just use the new code path in rollup@3 and delete the old

In newer versions of Rollup the { preserveModules } option can also output CJS/AMD

Is it a blocker?

[36degrees]

Gotcha, so once we've upgraded to v3 we'll be able to simplify this?

[colinrotherham]

Exactly. In this PR we process:

1. Entry point *.mjs files for ESM, top level only
2. Every non-test *.mjs file for UMD, recursively with **

task.name('compile:ms', () => scripts.compile('!(*.test).mjs') // Entries all.mjs, common.mjs etc
task.name('compile:js', () => scripts.compile('**/!(*.test).mjs') // Every non-test *.mjs file

But in future we'll use entry points for both and let Rollup discover all child modules.

[36degrees]

OK, that makes sense 👍🏻 Happy to leave this for now then.

[colinrotherham]

We tried this in #3462 but we'd have to output CommonJS rather than the hybrid Universal Module Definition (UMD) bundles for browsers (see comment)