Why Not Emit Both CJS and ESM Versions Using a Bundler?

[erikyo]

In considering the building process, we could implement a bundler like Tsup, which would facilitate the creation of a bundle compatible with both ESM and CJS formats.

I recently encountered this issue within an npm module that relies on gettext-parser as a dependency, which exposes a CommonJS (CJS) binary script. Consequently, I find myself compelled to utilize an older version of gettext-parser.

I believe implementing this change could offer several benefits for individuals like myself, who utilize it with a CLI script, or for those who, due to various constraints, must resort to using CJS.

[smhg]

Isn't CommonJS basically the past?
I think a lean (maintainable) code base is more important here.

Supporting outdated (coding) practices is something that is fine to drop between major versions if you ask me. Otherwise you end up with the Python 2 vs 3 story.
That's different for core functionality (think different gettext standards).

an npm module that relies on [outdated] gettext-parser as a dependency

The obvious solution would be to fix that module I guess.

[erikyo]

ESM is experimental since nodejs >18 (anyway still experimental in 22), you can transpile and bundle the code as you need but actually the preferred target for node is cjs
https://nodejs.org/api/esm.html#modules-ecmascript-modules

Hopefully isn't like Python and you can "parallelize" different output format and then provide the different paths using package.json
https://nodejs.org/api/esm.html#enabling

this is an article that explains nicely the issue, i 100% share the same feelings with the author:
https://blog.devgenius.io/stop-publishing-esm-only-packages-do-this-instead-8488c1a289ab

[smhg]

Is it possible Node 22 solves this for CommonJS users?
https://nodejs.org/en/blog/announcements/v22-release-announce#support-requireing-synchronous-esm-graphs

[erikyo]

nope unluckily, because that work for common js module used in the es format but not the opposite.

It's a thorny issue but the two standards are incompatible and if you opt for one single support your risk is to cut off a part of the user base (or making them, like me, revert to very old versions ref.)

[erikyo]

The obvious solution would be to fix that module I guess.

Just to provide better context, in that repository, I'm using Tree-sitter, which is an AST parser written in C and bound to Node using NAPI.

NAPI is CJS only (at the moment), and Node is natively CJS too. My repo was originally ESM, but due the inability to mix cjs and esm correctly (which forced me to make a bundle with the transpiled esm repos). The module is a parser that, thanks to Tree-sitter, can parse and extract translations from hundreds of files per second (then I use Gettext parser to generate the .pot file).

For me, it is crucial that it works correctly, and with ESM, it does not. This is why I recommend a dual bundling; the repository is risking to excluding many who use Gettext parser with CLI scripts. I also have examples that demonstrate this, for instance, the WordPress I18n package, which has a CLI script.