☂️ Convert to ES modules

[connorjclark]

Not breaking changes:

• Report renderer
• Convert report renderer to esmodules (perma-draft PR) #12623
• report: move renderer code to report/ #12690
• report: convert to ES modules #12702
• Viewer clients(viewer): convert to ES modules #12878
• Treemap clients(treemap): convert to ES modules #12892
• Extension (this code is isolated and never touched so we could skip/defer until next change) clients: convert extension to ES modules #14181
• Client entries (CDT and LR) clients: convert devtools and lightrider entries to ES modules #13722
• CLI cli: convert to ES modules #13045
• Collect strings (support collecting from ES modules) scripts(i18n): support es modules in collect-strings #12741
• Scripts misc: convert lighthouse-core/scripts to ES modules #13121
• Tests tests(smokehouse): convert to ES modules #13046
• Lighthouse Logger core(lighthouse-logger): convert to ES modules #13720
• Build misc(build): convert to ES modules #13967
• misc: remove 'use strict' from module code #13869

Breaking changes, wait for v10:

• Core
  • Tests misc: convert lighthouse-core/test to ES modules #13295
  • locales.js: use fs.readFileSync or change locales to .js files misc: read locale files without using require #12721
  • core(config): make module resolution async #13974
  • ... more sub tasks ... (TODO: work this out)

doc
(below is just some repeated info)

---

Changing CLI to esmodules isn't breaking?

Nope–the interface for the CLI is via the command line, not programmatic.

How to breakup work?

Reminder: ES modules can import commonjs, but the inverse is not possible (not without doing async imports). Therefore chunks of code with no dependents should be converted first.

Scripts and tests use modules from everywhere, so those should be converted first.

The report renderer, viewer, treemap, extension, CLI, scripts and tests can all be done independently, one at a time as they have no dependents (also mostly true for individual tests and scripts, but the dependency chains there are small).

Core is a big beast, and has the hardest problems to work out (I'm thinking of the config dynamic module loading code). The CLI depends on Core, so CLI must be converted first. Once lighthouse-core/runner.js and lighthouse-core/index.js is converted, and the config module loading is worked out, should be able to do each folder in lighthouse-core individually (but at this point, with everything else done, it may be reasonable to do all of it at once). See https://gist.github.com/connorjclark/22105a01b471811d9c5ccf989db3059d for part of the dependency list (doesn't include any dynamic modules).

The package.json type field is what enables esmodules (we don't want to do .mjs), and luckily the nearest package.json file is used, so during the transition we can just write {type: "module"} files where necessary.

Lighthouse Logger

This will be cumbersome since it is its own package. Should we move this into Lighthouse proper as lighthouse-core/lib/logger? We could defer updating the npm package until necessary, and drop the dependency on lighthouse-logger; that should allow us to convert this code w/o a breaking change.

EDIT: turns out this is simpler than all that. see #13720

Read more

https://electerious.medium.com/from-commonjs-to-es-modules-how-to-modernize-your-node-js-app-ad8cdd4fb662

[brendankenny]

jestjs/jest#10025 ("jest.mock does not mock an ES module without Babel") seems like it will likely be an issue for us on the testing side. A draft PR is up to fix it (jestjs/jest#10976), but has been open for seven months and doesn't look to be a priority for them right now.