NPM 包未来趋势是用 ES Module 吗

不太可能，python2 到 3 用了 12 年，放弃 cjs 的代价只会更大，毕竟 npm 那个递归引用设计。。。

是的

浏览器端是, 服务端不太可能

不用怀疑，就是未来趋势，本就是为了解决 cjs 的痛点

如果是 TS 的话一律用 ESM 就完事了，编译的时候可以根据需要，自行选择输出为 ESM 、CJS 、AMD 、UMD 格式。

不是未来趋势，而是已是现实
不过好在转了 esm 后还能用 cjs 的，只不过只能整个引入模块，稍稍不方便一点点

cdn 服务都开始支持了

浏览器都支持了，esm 肯定是标准的标准

是的。而且 esm 引入 cjs 模块的成本不大，cjs 通过 import()仍然可以引入 esm 模块。

node_module 这个黑洞迟早被淘汰

是的，现在构建工具都依赖 esm 实现 no-bundle ，比如 vite

@DOLLOR TS 在 Node 端使用 ESM ，相对路径需要加上 .js ，目前还是很不友好的

```
relative import paths need full extensions (we have to write import "./foo.js" instead of import "./foo")
```

只有我一个现在是 Nodejs 用 点 mjs 文件写吗？

@Inocr 并不需要加.js ，都是运行时在命令行上加 --es-module-specifier-resolution=node ，这样和原来不样不用.js 。 加.js 是麻烦，因为和前端不能共用文件了（或需要特别配制）。

@makelove 好吧，当时一看提示 ExperimentalWarning ，就有点怵，毕竟要上生产。那就只有个 tsconfig paths alias 需要解决下了，谷歌了很方案，都没有找到合适，不过这个问题倒不是很大，改成相对路径就好

加"type"="module"就行了，现在 nodejs 的 lts 版本已经是 16 了

个人认为，主流场景下，建议以 ECMAScript 官方标准为导向，官方出了 ESM ，将来大方向就是逐渐迁移到 ESM ，如果 ESM 本身不完善，那么就肯定会去完善 ESM 本身，毕竟 ES 标准迭代挺快的。

deno 默认 esm 就可以 top-level await ，用 node 的时候不改 esm 模式都不舒服

是的