Closed conartist6 closed 3 years ago
IMO it's best to keep the source in the same module format as how it's published, be that CJS or ESM. This way you can ensure clean and predictable results, without weird default interop helpers and things being inserted in the published code via transpilation tooling. In fact, I don't recommend transpilation at all for published packages. I started out following the crowd by transpiling, then trying hard to optimize the results of transpiling, but making the switch to publishing what you write has been a game changer for quality and maintenance.
As for deciding which format to publish, I can offer extremely nuanced information about all the pro's and cons, having published CJS, ESM, and dual mode packages for years and learned a lot of hard lessons.
If you decide to write and publish ESM, it's fine if your dependencies like nearley
are CJS, because ESM can reliably import CJS (but not the other way around).
Yeah so the right choice here may just be to stick with cjs. I don't need a default export so there shouldn't be any interop trouble, and I can include the extra mjs
indexes like you say.
I'll have to think where to go from there though.
I am closing this as I am keeping cjs for now.
If I recall I used commonjs because
nearleyc
produces parser grammars in commonjs and I didn't want to deal with interop in the early prototyping phase.Now that I look I see that my current build is actually a complete noop because it is only transpiling esm which there is none of in the project.
There are serious advantages to having the source in esm which I think make the change back worth it, including better help from the linter in this project and better interop with esm environments and tools, especially native esm environments which may not have support for hacks like
__esModule: true
.