[SPIKE] Add bundled-only "browser" package exports

[colinrotherham]

This spike adds "pre-bundled" package.json "browser" exports whilst defaulting to separate modules

Whilst not included in this PR, we could resolve UMD for browser-based bundlers alongside CommonJS

(For example, Browserify and webpack v4)

".": {
  "browser": {
    "sass": "./dist/govuk/all.scss",
    "import": "./dist/govuk/all.bundle.mjs",
    "require": "./dist/govuk/all.bundle.js",
    "default": "./dist/govuk/all.bundle.js"
  },
  "sass": "./dist/govuk/all.scss",
  "import": "./dist/govuk/all.mjs",
  "require": "./dist/govuk/all.cjs",
  "default": "./dist/govuk/all.bundle.js"
}

Split out from:

• Default to ES modules with single Rollup config #3726 (comment)

Includes a commit from #3906 to improve our export test output

[romaricpascal]

Digging around a bit, it seems that neither Browserify¹ nor Webpack 4² would use that field. Is this field meant for other tools/versions? Or is it mean to be browser at top level, which both would understand (but double up with main which they already understand).

Footnotes

1. Judging by its documentation Browserify looks at main and browser at the top level of package.json rather than inside exports ↩

2. Support for exports in package.json seems to only have landed in Webpack 5 so wouldn't be used by Webpack 4 ↩

[colinrotherham]

@romaricpascal Sorry I didn't explain very well 😆

Remember we tried compiling separate CommonJS modules?

This PR would let unpkg, webpack 4 and Browserify stay on top-level "browser" as UMD

But modern bundlers get require() or import (with tree-shaking) via package exports as CommonJS, but we'd still offer a route for those applying a "browser" condition to get bundles if needed

[romaricpascal]

None of these tools mention a browser field inside exports for getting their dependency (webpack and Browserify talk about one at the top level of package.json, and Unpkg mentions its own unpkg field). So what I was trying to clarify is whether the configuration was in the right place.

Thinking on it some more, I think until we get a clear demand for automatically linking to an UMD build for these old bundlers, we should avoid adding more complexity to our exports. People can require the relevant path in their code, so wouldn't be blocked. That's also one less path that govuk-frontend may resolve to, which simplifies support.

If demand comes in, though, happy to look into it further. The change wouldn't be breaking anyway as people using the full path wouldn't be forced to make the update.

[colinrotherham]

Yeah, don't worry, hope it's clearer now

Definitely, we split this PR out when CommonJS was removed in #3726 (comment)

Won't need looking at again unless we drop UMD as the default for require()