(Previous discussions: #133, #269)

Summary

I'd like to start a long-term clean-up project which aims at the following:

• Simplify the build pipeline and reduce the number of dev dependencies.
• Focus on natively supporting ES modules in browsers and in Node.
• Increase the usefulness of CI testing.
• Don't break the current compatibility of compat.js builds.

The Status Quo and Its Problems

• We currently don't support ES modules in Node.js.
  • As of Node.js 13.2, only files ending in .mjs or files under a folder hierarchy with a package.json with {"type": "module"} can be imported rather than required.
  • We have neither.
• Our build pipeline is complex.
  • We use Rollup to bundle our files.
    • It's not really needed for using Fluent in Node.js and as a dependency for larger projects with their own build pipelines.
    • OTOH, a single-file package is easy to include Fluent in jsfiddle, codepen etc.
      • Then again, all of modern browsers support <script type="module">.
  • We use Babel to transpile the compat.js build.
    • We use preset-env to define what should be transpiled. The browser matrix was chosen not based on usage data, but based on the JS features we didn't want to transpile. That's kind of backwards of how preset-env should work.
  • In Migrate to TypeScript? #376 we're talking about adding TypeScript to the mix, which would further complicate the pipeline, testing, debugging etc.
• We write tests using ES modules and make them work in Node by patching require.
  • This is done using @babel/plugin-transform-es2015-modules-commonjs or esm.
• We test code in different version of Node (good), but we do it by transpiling our unit tests with a Babel setup which is different from the one which we use for shipping (bad).

Short and Mid-Term Ideas

I'd like the clean-up to be careful and incremental. In no particular order:

• Add integration tests.
  • Create a new test suite using our compat.js builds and run it in different versions of Node and older browsers without any further transpilation.
  • Switch our unit tests to only run in the currently active version of Node.js.
• Drop preset-env and transpile to ES2017 which we effectively do right now anyways.
• Ship ES modules next to CommonJS files.
  • There isn't an established good practice about how exactly to do it right now.
  • Node.js has some docs about proposed approaches.
  • The blog post (same as above) mentions January 2020 as the target date for finalizing the official docs about this.
• Maybe drop Rollup?
  • Once we fully support ES modules, will there still be a strong case of bundling our files in a UMD package?
• Maybe migrate to TypeScript?
  • See Migrate to TypeScript? #376 for the discussion about TypeScript.
  • One more tool in the pipeline, but..
  • ...we could possibly drop Babel thanks to TypeScript's target compiler flag.

Long-Term Ideas

Some further ideas for when all Node LTS versions support ES Modules without flags (from mid-2022 forward).

• Drop CommonJS
  • Node 12 will be EOLed in April 2022.
• Drop esm and @babel/plugin-transform-es2015-modules-commonjs when running tests.
  • This requires that we use a test runner which natively supports ES modules. Work is underway in both mocha (which we currently use) and jest to enable this.
  • It might still be months away today, as it likely requires the "custom loaders" API to stabilize in Node.js. See the bottom of this blog post.