javascript - Requirejs vs browserify vs webpack for js 加载顺序 : am I just moving the situation from one side to another?

Question

好吧，现在是 2016 年了。Webpack看起来像是对 requirejs 的赢家和 browserify .我一直在阅读这 3 种技术，以解决一个非常具体的问题。 我想在我的 HTML 文件(AngularJS 应用程序的一部分)中避免这种情况

<script src="some-file.js"></script>
<script src="some-file2.js"></script>
<script src="some-file3.js"></script>
<!-- Dozens of similar lines here... -->

当然，我的 HTML 文件中这些行的顺序很重要。 Bootstrap 会要求 jQuery 等。

我发现的第一件事:requirejs。您只需指定如下内容:

<script src="my-bundled-file.js"></script>

然后，你用JS解决依赖问题。更进一步，我在这里发现了两种方法:

• CommonJS(浏览器化)
• AMD(require.js)

Webpack 适用于这两种方法，这听起来不错。

最后，这 3 个工具可以用于同一件事:将多个文件捆绑在一个文件中。但我担心的是这些文件的捆绑顺序。

我不想关心这个，看起来像使用那些解决方案(或者甚至 gulp + gulp-concat，就像建议的那样 here )，我只是在移动问题:现在，我指定我的应用程序使用 JS 代码的模块，但我仍然需要以正确的顺序放置模块，即使使用 WebPack(示例 here:require 调用必须在正确的顺序)

所以，我的问题:

• 我是不是误解了这些工具？只想解决加载顺序问题，貌似没做
• 这些工具是否解决了不同的问题(ES5 中缺少原生模块，这会导致污染全局范围)？

Answer 1

am I misunderstanding these tools? I just want to solve the loading order problem, and looks like I'm not doing it

我想是的，是的。使用 CommonJS 和捆绑它的工具，加载顺序在很大程度上变得无关紧要，这是您不需要管理的事情。您只需在需要的地方require() 即可。在某些情况下它仍然相关，但主要与全局副作用和循环依赖性等问题有关。使用 CommonJS 并将其捆绑与连接一系列脚本完全不同。

do these tools solve a different problem (lack of native modules in ES5, which drives to contaminate the global scope)?

CommonJS 模块系统旨在解决 JavaScript 中缺少原生模块的问题，它的一个版本用于 Node.js 中。 Browserify 上的标题是“为浏览器捆绑节点模块”，尽管实际上它也用于创建在 Node 中运行的 bundle 以及仅用于在浏览器中运行的捆绑模块。

在 Node 中，不需要捆绑模块，因为 Node 包装了您执行的代码并为其模块语义提供了实现。要在浏览器中使用该系统运行模块，您需要将其捆绑，因为浏览器不会包装代码以向其提供构成模块接口(interface)的内容，例如 require()、模块，导出。这是 bundler 为您做的部分工作:包装代码以提供该接口(interface)。

它为您做的另一件事是递归地发现依赖关系，解决您关于排序的问题。所以就像我说的那样，您可以在需要的地方require() 获取所需的内容，并将 bundler 指向入口脚本。 bundler 将分析脚本以查找任何 require() 并将它们引用的模块包含在 bundle 中。对于这些模块，它将无限重复。

我认为您会发现 CommonJS 比 AMD 更有吸引力，但我想说 Webpack 远未明显胜过 Browserify。两者都很受欢迎。 Browserify 被广泛使用，包括构建部分项目，如 Babel 和 React。

我的建议是从 Node 风格的 CommonJS 模块和 Browserify 开始(注意:我是 Browserify 的维护者)。

在您更好地理解这一点之前，我建议不要使用涉及 Angular 的任何内容作为引用，以了解如何根据 CommonJS 模块化来完成工作。我认为他们在将 Angular npm 包转换为正确的 CommonJS 形状时遇到了很多麻烦。