Giters

Chatie / tsconfig

tsconfig.json inheritance via Node.js packages

Home Page:https://npmjs.com/package/@chatie/tsconfig

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

huan opened this issue · comments

commented

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!

commented

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.

commented

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/

commented

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.

commented

you can use either import or require for our package.

👍👍👍

commented

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.