Borewit/music-metadata

ESM, CJS, and everything

martpie opened this issue · 4 comments

martpie commented

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

Borewit commented

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.

martpie commented

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!

  • 👍1
Borewit commented

I am dropping CommonJS support, it became undo-able to maintain both branches, for each package system, an this repository and all the underlying packages.

ESM usage is becoming the standard and the benefits are becoming visible. With release v9.0.0 there is version without polyfill requirements when used in the browser.

  • 👍1