Convert package to ESM

[nzakas]

To convert this package from CommonJS to ECMAScript modules (ESM):

• Add type: module to package.json
• Convert files in lib to ESM
• Convert files in tests/lib to ESM
• Upgrade Mocha
• Create build script in package.json to generate CommonJS file (.cjs) in dist directory (use Rollup)
• Add dist to .gitignore
• Run build in prepare script in package.json to ensure build is run at key moments
• Update package.json so that main points in the CJS file in dist and exports provides both require and import options
• Update README instructions

[ljharb]

You don’t need type:module at all; that’s only if you want .js files to be ESM (which will break back compat and a number of tools). I’d suggest using .mjs for ESM instead.

[nzakas]

We want .JS files to be ESM.

[brettz9]

Just a note that due to there being a number of dynamic require's (some for the performance benefits of lazy loading but others necessarily so) and with import() being async, a number of methods (config-array-factory.js) will need to end up as async.

[brettz9]

Another question raised is whether you want to change the files which export objects like:

module.exports = {
  method1,
  method2
};

...into named exports (as can support tree-shaking) like:

export{
  method1,
  method2
};

...even though one technically could continue to export as a default object like:

export default {
  method1,
  method2
};

[nzakas]

We can’t change methods to be async because these APIs are frozen. If that’s a blocker for this effort, then so be it. Ultimately this package will be used infrequently once the new config system is in place, so it’s a lower property to convert.

[brettz9]

Yeah, ok, appears it will be a blocker then.

[brettz9]

Wait, maybe need to take another look as it may be requiring JSON which could be safely read synchronously.

[brettz9]

No, it looks like at least _loadParser and _loadPlugin would need to eval the contents.

[nzakas]

Could we use createRequire in those cases?

[brettz9]

Oh, wonderful. I had just associated that mentally as a workaround for JSON. :-) Will see if I can complete the work then.

[brettz9]

This would presumably mean that the parser and plugins could not be expressed themselves (without a build step) as ESM yet though.

[brettz9]

For the cases where some require statements could be expressed as import but which are currently not at the top-level and lazy-loaded for purposes of performance, would you like me to continue to use require and just trust that the projects (js-yaml and espree) will not be abandoning a CJS version anytime soon, or express them as top-level imports?

[nzakas]

Presumably no dependencies would eliminate CJS without a major version change, so I think we are safe using require. (As previously mentioned, these APIs are frozen so we won't be doing any upgrades of dependencies.)

I think it's probably safe to use import for anything that can be statically referenced and just use require for anything dynamic.