使用ES6模块和npm模块的最简单方式是什么？并且使用import/export语法。

Question

目前，ES7模块已经在几乎所有浏览器中得到了普遍支持。旧的解决方案似乎涉及使用babel与Browserify或Webpack。这仍然是使用ES6导入/导出语法处理本地和npm模块的最简单且得到充分支持的方式吗？

- Krombopolis Michael

---

因为有些人使用的浏览器不支持 import / export。 - bill.gates

我投票关闭此问题，因为它更像是一篇抱怨而不是一个具体的问题。如果这里有一个真正的问题，请尝试去掉所有观点和额外内容，并将其提炼成一个简单的问题。如果没有，也许这是一个写博客文章的好主题。 - Evert

那很公平。我知道里面肯定有个问题，但我真的很难提炼它。我保证我不只是想发泄一下（尽管感觉确实很好） - Krombopolis Michael

好的，我试图摆脱控诉并将其缩减为仅问题。 - Krombopolis Michael

据我所知，浏览器仍然不支持“有用”的模块标识符解析（尽管正在开发导入映射），除非您已经设置了一个了解模块依赖关系的HTTP2服务器，否则您仍然需要提供一个捆绑包而不是每个模块文件单独提供（并且您肯定不想只提供您的/node_modules文件夹）。 - Bergi

Answer 1

TLDR: 使用bundler仍然是发布/打包应用程序的最佳方式。

这不仅仅是一个模块的问题，更多地涉及服务器拓扑和整体打包。

例如，您有一些第三方npm模块，它们提供ES模块，即import/export语法。它通常会安装在node_modules文件夹中，它的依赖项也是如此。现在，您要在代码中使用此模块，您希望像这样使用它：

import xyz from 'my-npm-module';

通过上述简单的语句，存在多个问题。以上类型的导入是非相对的导入。对于 Node.js 或者 Webpack 或 Rollup 等打包工具，这只需要从当前目录开始查找 node_modules 文件夹，并一直查找到根目录即可。

现在，浏览器没有这种非相对的导入解析知识（浏览器不使用 Node 模块的解析方式）。所以第一个问题是，浏览器如何知道在服务器上查找这些模块的位置。第二个问题，假设你以某种方式教浏览器使用非相对的模块并遵循 Node 风格的解析算法，你仍然需要打包整个 node_modules 文件夹，包括子目录。这是一个非常繁琐的过程，并且会使应用程序的最终构建大小无端膨胀。

这些都是你仍然需要使用像 Webpack 和 Browserify 这样的打包工具的原因。为了保持简洁，如果你不想支持旧的 JS 引擎，可以跳过 Babel。然而，如果你真的想要在浏览器中使用和传送 ES 模块，请考虑使用支持输出格式为 ES module 的 Rollup.js，而不是 Webpack 的 UMD 或 Common.js。

另一种选择是使用 System.js + JSPM 的应用程序打包方式，其中 ES 模块是默认的，但它没有像 Webpack 或 Rollup 那样的灵活性。此外，还有一种新的打包器——Parcel.js，旨在成为零配置解决方案，并且非常容易使用。你不会注意到所有复杂的细节。

最后，现实世界中的前端打包不仅仅涉及 JavaScript。还有其他的资源文件，例如 TS 文件、ReasonML 文件、图像、SVG 文件，你可能想要将其编译和打包到最终的文件中，使用高级优化技术如 Tree shaking 和 HMR（开发模式），这些打包工具真正擅长于此。

- Harshal Patil

---

谢谢，这解释了很多问题。我非常喜欢使用Parcel，并且对为什么需要更复杂的打包工具有了更好的理解。但是，为什么我必须使用非相对导入呢？如果只使用以下简单方式，我会非常高兴：import xyz from '..node_modules/my-npm-module';为什么不可能呢？ - Krombopolis Michael

浏览器不使用Node风格的模块解析，这就是问题所在。它们应该使用，并且有人应该编写一个强制浏览器使用Node风格模块解析的插件。 - Szczepan Hołyszewski