reexports detection incompatible with output from Rollup@^2.39.0 about cjs-module-lexer

[yyx990803]

/cc @lukastaegert

[nicolo-ribaudo]

Previously, these packages "just worked" for named imports from Node.js in ESM mode because cjs-module-lexer was able to detect the re-exports

Note that it's probably too late to make it work again in Node.js 12 so probably many users will be stuck with getting "named" import from the default import.

[LinusBorg]

PR that introduced the change in rollup: rollup/rollup#3959

[lukastaegert]

cc @guybedford

[lukastaegert]

Seems weird to me why this change would break the lexer, but I am no expert on this matter. For Rollup, it fixes a serious bug and improves spec compliance.

[nicolo-ribaudo]

@lukastaegert It's because the new Rollup output has changed, and it doesn't match anymore the patterns recognized by this package (specifically, EXPORT_STAR_LIB in https://github.com/guybedford/cjs-module-lexer#grammar).

Fwiw, as a Babel maintainer I will never consider the generated output that cjs-module-lexer relies on part of the public API and thus I'll break it when needed even in patch releases. I love that Node.js uses this package to make it easier to import cjs dependencies, but:

• It's meant to be used when importing a old cjs packages: since they are "old" they won't unpdate their Rollup/Babel dependencies, because a new release would make them "new"
• New packages shouldn't rely on this Node.js cjs interop since it's inherently unstable, but they should provide a proper ESM entrypoint with curated exports.

I'll still try to notify @guybedford (or even open a PR) whenever Babel's exports output changes.

[yyx990803]

It is an unfortunate combination and I too feel that tools should not have to cater to what cjs-module-lexer is able to detect when performing code generation. However the reality here is due to its use in Node.js this can cause unintended breakage for existing packages by simply upgrading the build tools (in this case Rollup, Babel or TS).

There are several aspects at play here:

• As package authors, I can introduce a dedicated Node esm build, however that requires introducing the exports field if previously not present, and can potentially be a breaking change;

• As tooling authors: it would be ideal not to have to care about cjs-module-lexer for code generation.

I understand why Node provides named imports interop for cjs modules, but it feels a bit flaky for it to be based on code-generation-pattern specific static analysis (which leads to this problem here).

[guybedford]

I've put together a PR in #41. There have been a few changes coming together here, so when the release is made I can work on getting this backported as far as possible on the Node.js release lines. Support on Node.js 12 may not be possible though unfortunately.

This project is very much a bandaid and a hack, bridging a divide that was never quite bridgeable. Hopefully we can avoid too much churn during this transition period.

@lukastaegert I've also added detection for Object.hasOwnProperty check in the same sort of way. If you can think of any other patterns you want to future proof now please put some thought to it - happy to add further changes into this.

The Node.js release cutoffs will start to become a problem with this project where we risk things working in modern Node.js then failing in older versions. For that reason we should try to avoid changes to this project as much as possible, or where needed to make them sooner rather than later while the backports are still possible.

[sodatea]

Hi @guybedford, please reopen this issue, because it's not fixed due to the typo here: https://github.com/guybedford/cjs-module-lexer/pull/41/files#r667619960