为什么 Node 经常使用与浏览器不同的模块系统？

Question

我正在考虑通过将以下行添加到我的 package.json 文件来更新我的 Node/Express 代码以使用import而不是require ：

  "type": "module",

但是，我不知道为什么我看到的大多数 Node/Express 代码仍然使用require ，而我在浏览器中通过 webpack 看到的代码使用 import。

这种双重性有原因吗？ 通常建议升级到导入吗？ 进口是因为它较新被认为是升级和更好的技术吗？

之前的 Q/A已有 7 年多的历史，并且包含大量历史信息。 随着语言的发展，我正在寻找更多最新信息。

Answer 1

拥有两种类型的模块的原因纯粹是历史原因。

早在 2009 年创建 Node.js 时，ES 模块（ import语法）还不存在，但存在其他非标准替代方案，最重要的是AMD和CommonJS ，有几种浏览器实现可用。 Node.js 决定采用 CommonJS（ require语法）。 因此，直到 2015 年部署的所有包都是 CommonJS 包。

原生 ES 模块是随 ECMAScript 2015 标准一起引入的，但它们只是在 2017 年的 Node.js 8.5 中将其作为一项实验技术，直到 Node.js 12（2019 年），它们的支持才变得足够好，可以将它们作为替代方案CommonJS（尽管这是主观的）。 出于这个原因，很大一部分为 Node.js 开发的软件仍然使用带有require语句的 CommonJS 模块。

ES 模块是否更好是一个见仁见智的问题，而不是 StackOverflow 的适当问题。 至少，它们是标准的 JavaScript ，这使得它们适合在浏览器和 Node.js 中使用，这是我的一大优势。

一个缺点是 CommonJS 代码中不能需要 ES 模块——反之亦然：CommonJS 模块可以由 ES 模块导入——所以如果你的任何依赖项使用 ES 模块，这可能是将你的代码切换到 ES 模块的好机会， 也。

那么我们应该升级到一般使用import吗？ 当然，这也是见仁见智的事情。 如果那是我的意见，答案将是“否”，因为没有理由更改正在运行的系统。 CommonJS 代码不会变成rust或仅仅因为现在有更好的选择而变得更糟，尽管 ES 模块是新代码的更好选择。 Node.js，只要人们使用它，也不会放弃对 CommonJS 的支持。

有一个名为Deno的项目旨在为 Node.js 提供更现代和更安全的替代方案，以在服务器上运行 JavaScript 代码。 Deno 最初设计为仅与 ES 模块一起使用，但很快就发现不支持 CommonJS 模块是一个主要问题，因为太多 npm 包无法正常工作，因此它引入了 兼容模式以在标志下支持 CommonJS 模块。 这个故事的寓意是：删除对require的支持是个好主意，但重新添加它会更好。