search

Chatie / tsconfig

tsconfig.json inheritance via Node.js packages
https://npmjs.com/package/@chatie/tsconfig
Apache License 2.0
3 stars 1 forks source link

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

Open huan opened 3 years ago

huan commented 3 years ago

Progress

Howto

Links

Badge

ES Modules

[![ES Modules](https://img.shields.io/badge/ES-Modules-brightgreen)](https://github.com/Chatie/tsconfig/issues/16)
suntong commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.
    1. 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 commented 2 years ago

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 commented 2 years ago

you can use either import or require for our package.

👍👍👍

suntong commented 2 years ago

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 https://github.com/padlocal/wechaty-puppet-padlocal-demo/issues/16

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