[RFC] artus 的默认运作模式选择 esm or cjs

[DuanPengfei]

现在有三个选项：

• 官方只支持 esm
• 官方只支持 cjs
• 同时提供 cjs & esm 支持

值得注意的是，第三个选项看起来美好，但是从长期看是给 artus 生态的可维护性挖坑

[atian25]

关键还是 Node.js 官方没能给出指引，导致社区类库开发者很混乱。
目前看来可能的选择就是 TS 写，然后同时编译为 2 个。

nodejs/node#33954
whatwg/html#5572

https://github.com/esm2cjs
nodejs/node#44186

[DuanPengfei]

关键还是 Node.js 官方没能给出指引，导致社区类库开发者很混乱。 目前看来可能的选择就是 TS 写，然后同时编译为 2 个。

nodejs/node#33954 whatwg/html#5572

https://github.com/esm2cjs nodejs/node#44186

这种就很精神分裂

[hyj1991]

我投 esm 一票，框架直接导出 esm，可以有效避免基于 require 和 js 原型链的 monkey patch 这种 hack，增加框架逻辑的可信度

[atian25]

我再想了想，还是面向未来吧，我们只编译为 esm 吧，不要同时兼容。
不然一方面我们的维护成本很大，有很多类似 __dirname 和 import.meta 的兼容。
另一方面，用户也很痛苦，像 sindresorhus 的很多库都没法用最新版本了。

而且我们 artus 是 runtime 运行时，一般不会被人 import。

[XadillaX]

ESM 有个问题，用户如果 require 就很痛苦...

[hyj1991]

ESM 有个问题，用户如果 require 就很痛苦...

官方可以明确只提供 esm 的编程界面的良好支持

[atian25]

ESM 有个问题，用户如果 require 就很痛苦...

artus 的用户应该都是用 TS 来写了，他为啥要 require ？ 他也不需要关注编译目标怎么选择，无脑 esm 就好了。

[hyj1991]

2022-08-30 飞书视频会议结论：

• @artus/core 继续保留 cjs 和 esm 两种导出方式
• 修改 build 脚本，通过在 package.json 中定义 exports 和 imports 来进行两种模块的支持

[fengmk2]

竟然选了一条最难走的路。

[DevXiaolan]

竟然选了一条最难走的路。

[DevXiaolan]

实际上我们发现， 如果是作为 framework ,就优先用esm ，因为esm 尚且有办法用cjs；而作为 lib 的话就用 cjs ，因为 cjs 谁都能用。
所以总的来说还是看自己的定位。
当然希望node官方给个明确的指示。