Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESM, CJS, and everything #1783

Open
1 task done
martpie opened this issue Jul 4, 2023 · 3 comments
Open
1 task done

ESM, CJS, and everything #1783

martpie opened this issue Jul 4, 2023 · 3 comments
Labels
question Question, clarification, discussion

Comments

@martpie
Copy link

martpie commented Jul 4, 2023

Has the question been asked before?

  • I have searched the existing issues

Question

Hey @Borewit 馃憢

As you noticed, many people are a little bit confused with the v8 being pure ESM. Could you help me understand if that's because you want CommonJS to die (understandable), or because you just wanted to support ESM?

If the latter, would you be open to a PR making v8 export both CJS and ESM? I can help with that :)

As you saw, Electron peeps are in a weird situation because Electron is not close to support ESM from the main process (v7 works well, yes). If you tell me that you intentionally don't want CJS, then feel free to close this issue :D

@martpie martpie added the question Question, clarification, discussion label Jul 4, 2023
@Borewit
Copy link
Owner

Borewit commented Jul 4, 2023

Hello @martpie 馃憢, my aim has been to build a complient and modern module. CJS or ESM has never been a goal by itself.

Note that both ESM & CJS are still both supported, yet my assumption was that ESM eventually will replace ESM. I did not want to release a different package of music-metadata, so major version 7 is CJS and major version 8 is ESM. So far these functions are from a functional point of view identical.

It was @sindresorhus who strongly pushed to migrate from CJS to ESM in some other repositories I contributed to and/or provided depent modules.

I wish I could support everyone with a single architecture, being in between CJS and ESM does not make the open source contribution more fun. Combine that with front-end backend and there are rough 4 different type of communities. I hope on the long run ESM and other evolutions bring that back to a single type.

@sindresorhus
Copy link

See this for why ESM + CJS is a bad choice: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c?permalink_comment_id=3850849#gistcomment-3850849

@martpie
Copy link
Author

martpie commented Jul 4, 2023

I've faced the CJS/ESM issue recently on a couple of personal packages, so let me offer a solution that's quite simple (imho), but requires some setup. I have done that to both teeny-conf and react-keybinding-component. Example commit to set them up.

  • use tsup for bundling, which will output both CJS and ESM
    • ex: tsup src/teeny-conf.ts --format esm,cjs --dts --sourcemap will output both + type definitions + source maps
  • making sure things work is annoying, we have tools for that!
    • publint will lint packaging errors
    • are-the-types-wrong will make sure types and ESM work correctly
    • ex: prePublish: yarn publint && yarn attw -P && yarn build

With those changes, you could publish both versions in a single npm package, and it would up to the bundler/runtime to require the correct one.

WDYT? :)

edit: just saw you new message, reading 馃憖

edit2: trap card!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Question, clarification, discussion
Projects
None yet
Development

No branches or pull requests

3 participants