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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

distribute ESM version #50

Open
benmccann opened this issue Apr 14, 2022 · 6 comments
Open

distribute ESM version #50

benmccann opened this issue Apr 14, 2022 · 6 comments

Comments

@benmccann
Copy link

I was wondering if you'd be open to a PR to convert to ESM and what your thoughts are about ESM vs CJS, etc.

@nfriedly
Copy link
Owner

nfriedly commented Apr 15, 2022

Yeah, I suppose we ought to do that. Fair warning, though: I just went through a similar transition with a different project, and was more work than it sounded on the surface.

The main thing I want is to keep backwards compatibility for existing users, so keep a CJS version and no require(...).default or other nonsense.

I suspect that the best way to do it is probably a thin ESM wrapper that just re-exports the existing CJS module and provides a named and/or default export.

@frandiox
Copy link
Contributor

@nfriedly Hi 👋 would you consider adding a small script to generate the ESM version?
Somewhat similar to this PR in cookie for the same purpose: jshttp/cookie#154

It doesn't add dependencies or anything, it just concatenates the CJS version with an extra bit of code in an .mjs file.

@nfriedly
Copy link
Owner

Hum, that's an interesting idea, I like the simplicity.

What I had been thinking about was converting it to typescript, and then having tsc run twice to output both esm and cjs versions of the library, but I've done that with a few other libraries and it's a decent amount of work each time.

If you want to send in a PR to add the conversion script, I'll go ahead and merge it in, and I'll punt typescript for some other day (or maybe never).

@nfriedly
Copy link
Owner

A couple of thoughts if we go with a generation script:

  1. It should add a comment to the top of the file along the lines of // this file is generated, see scripts/build-esm.js
  2. There should be at least a small .mjs test that imports from the generated file and ensures it works

@benmccann
Copy link
Author

I also wonder if it should go in the opposite direction. Start with esm source and then generate the cjs version. Esm will be around longer-term and eventually everyone will be dropping cjs. That would make it easier for this library in the future as then you can just drop the generation script when the time comes and don't have to update the source

@nfriedly
Copy link
Owner

Start with esm source and then generate the cjs version.

Yeah, that makes sense.

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

No branches or pull requests

3 participants