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

Support ESM module (Dual-ESM-CJS-module) #16

Open
39 of 49 tasks
huan opened this issue Mar 17, 2021 · 6 comments
Open
39 of 49 tasks

Support ESM module (Dual-ESM-CJS-module) #16

huan opened this issue Mar 17, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@huan
Copy link
Member

huan commented Mar 17, 2021

Progress

Howto

Links

Badge

ES Modules

[![ES Modules](https://img.shields.io/badge/ES-Modules-brightgreen)](https://github.com/Chatie/tsconfig/issues/16)
@huan huan added the enhancement New feature or request label Mar 17, 2021
huan added a commit to wechaty/puppet that referenced this issue Mar 17, 2021
@huan huan pinned this issue Aug 25, 2021
@huan huan changed the title Support ESM module Support ESM module (Dual-ESM-CJS-module) Aug 26, 2021
@suntong
Copy link

suntong commented Feb 19, 2022

Howto

Thanks for providing all those informative links for us to read @huan, So

Switching the default from CJS to ESM would be a big break in backwards compatibility. ...
CJS can’t require() ESM because of top-level await

Would you explain just in high level what your strategy is please @huan? Especially, are you going to follow the recommendation to

Provide a CJS version of your library

Thanks!

@suntong
Copy link

suntong commented Feb 19, 2022

I meant, this is how I've been consuming wechaty in my plain JavaScript app:

const {
  Wechaty,
  ScanStatus,
  log,
}               = require('wechaty')

And I presume lots of JavaScript developers are doing the same thing as well.

Would you explain just in high level what your strategy is please

At the very least, what we JavaScript developers should do, after such transition is finished? Hopefully "Dual-ESM-CJS-module" means that we can still use our existing scripts without huge alternations. thx.

@suntong
Copy link

suntong commented Feb 19, 2022

Migrating

There are two ways to move your packages to ESM:

  1. Pure ESM
    This has the benefit that it's easier to set up. You just add "type": "module" to your package.json, require Node.js 12, update docs & code examples, and do a major release.
  2. Dual --- ESM with a build step that transpiles a CommonJS fallback
    This requires you to also set up a build step and add a exports field to your package.json. Read more
    Note that there are many downsides.

Personally, I plan to do 1 as I think it's better to rip off the bandaid and push the ecosystem forward.

(taken from https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77 which is now gone but mirrored at here)

Hmm..., maybe it is time to take plan #1... See:

https://ar.al/2021/01/27/commonjs-to-esm-in-node.js/

@huan
Copy link
Member Author

huan commented Feb 20, 2022

Yes, the ESM is the future and we should take it as soon as possible.

However, for maximum compatibility and a better developer experience, the Wechaty community strategy is to build a Dual-CJS-ESM package, which is what this issue is tracking about: you can use either import or require for our package.

@suntong
Copy link

suntong commented Feb 21, 2022

you can use either import or require for our package.

👍👍👍

@suntong
Copy link

suntong commented Jun 26, 2022

you can use either import or require for our package

I tried, but one works and one doesn't.
the two code is almost the same. Here are the key changes:

image

and now it is working. Ref padlocal/wechaty-puppet-padlocal-demo#16

So I'd conclude that the ESM module support is still broken, unfortunately.

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

No branches or pull requests

2 participants