Adding type: module to support native ESM imports

[brettz9]

Currently in attempting a native Node ESM import, I am required to use default (since native Node doesn't know to look up module, it will treat it as CommonJS, and look to main, and the main file defines it on default).

Ideally, the package.json for this project would have type: 'module' (and perhaps exports in place of, or in addition to, module). See https://nodejs.org/api/packages.html .

[brettz9]

Just to be clear, I really think this is effectively a bug, but since it had been working in the other environments which were in use at the time, I hesitated to file it as such. But one is indeed not able to use your package from native Node ESM without using default.

[longlho]

we tried it a while back and it completely broke the ecosystem because not everyone's ready for mjs. TS doesn't even compile to mjs and mjs has very specific requirements regarding how modules are imported/exported.

[brettz9]

I wonder if that could have since changed. With Node 10 being end-of-lifed, members of the community have been promoting the move toward ESM.

By setting type: 'module' in package.json, one can use ".js" instead of .mjs for ESM (making ESM the default unless ".cjs" is used), and instead use ".cjs" for CommonJS.

Significantly older browsers might admittedly only work with ".js", but I'm not sure how big of a concern that is today. Certain tools (Webpack) indeed have problems allowing even browser builds with ".js" when there is type: module because Webpack, unlike Rollup apparently, goes through the browser exports expecting them too to be ESM with type: module; so for the likes of Webpack at least, it seems one cannot use ".cjs" just for Node and ".js" for UMD and ESM. But if passing the browser ".cjs" or such, there should be no issue from any of the current regular ESM environments.

If you don't go with "type: module" to try to avoid this (and use ".mjs"), there is still the TS issue apparently, but it seems there may be a workaround for that.

So as far as I can tell, you should be able to:

1. Use ".mjs" now with the Rollup workaround for TypeScript
2. Use type: module and not worry about older browsers which can't handle non-".js" extensions, and use an extension like ".cjs" which can be shared by Node and the browser for UMD builds.

[longlho]

yeah ill wait till TS supports mjs.

[remcohaszing]

Since these packages don’t support real ESM, the CJS variant is used. Because the CJS uses a format that Node.js can’t consume using named imports, it can be used like this:

import IntlMessageFormat from 'intl-messageformat'

const message = new IntlMessageFormat.IntlMessageFormat()

However, the TypeScript types don’t match. I think this makes it a bug.

The following steps would fix it:

• Create lib/package.json with the following contents:

  {
    "type": "module"
  }

• Use a .js file extension for imports.

[remcohaszing]

An alternative fix would be to add index.mjs in the root of each package. This then creates exports for all CJS fake named exports.

I.e. for intl-messageformat:

import IntlMessageFormat from './index.js'

export const PART_TYPE = IntlMessageFormat.PART_TYPE
export const isFormatXMLElementFn = IntlMessageFormat.isFormatXMLElementFn
export const formatToParts = IntlMessageFormat.formatToParts
export const IntlMessageFormat = IntlMessageFormat.IntlMessageFormat
export const ErrorCode = IntlMessageFormat.ErrorCode
export const FormatError = IntlMessageFormat.FormatError
export const InvalidValueError = IntlMessageFormat.InvalidValueError
export const InvalidValueTypeError = IntlMessageFormat.InvalidValueTypeError
export const MissingValueError = IntlMessageFormat.MissingValueError
export default IntlMessageFormat.IntlMessageFormat

In addition I think the main field needs to be removed from package.json then. This is fine, as it’s the default (index.js) anyway.

Although I consider this more as a workaround than as a proper fix.

[longlho]

the blocker is TypeScript supporting mjs output

[brettz9]

It sounds like you want to wait for more stability, but just FWIW, there is experimental support apparently against nightly TypeScript per https://www.typescriptlang.org/docs/handbook/esm-node.html#new-file-extensions

[longlho]

yeah I'll wait for that to be fully baked