angularjs - export/module.exports 有什么用？

Question

今天我在我的 AngularJS 项目中采用了 Browserify，但是我还不清楚。在所有示例和博客文章中，我都看到了这样的东西:

/app.js:

require('./messages');
angular.module('sling', ['sling.messages']);

/messages/index.js:

exports = angular.module('sling.messages', [])
    .controller('MessagesListCtrl', require('./MessagesListCtrl'));

/messages/MessagesListCtrl.js:

module.exports = function() {
    // ...
});

当然，这行得通，但为什么要这样做？我已经像这样实现了它，而且效果也非常好，并且对于 AngularJS 项目来说感觉更正常:

/app.js:

require('./messages');
angular.module('sling', ['sling.messages']);

/messages/index.js:

angular.module('sling.messages', []);
require('./MessagesListCtrl');

/messages/MessagesListCtrl.js:

angular.module('sling.messages').controller('MessagesListCtrl', function() {
    // ...
});

换句话说，我完全跳过了exports/module.exports，只使用了 require。基本上包括带有 Controller 、服务、过滤器等的文件。

我这样做对吗？我的意思是这一切都有效，但我以后会遇到麻烦吗？

Answer 1

使用 Browserify 的主要(并且是唯一的)原因是如果你想在浏览器中拥有 CommonJS 模块(即 NodeJS 模块)。 CommonJS 模块通过隐含的“模块”范围保持在全局范围之外。您可以通过扩充每个模块具有的“导出”对象来选择从模块范围(通常是模块的入口点或主要功能)公开的内容。

所以一个“真正的”CommonJS 模块看起来像这样。

文件一:

// a.js

function doSomething() {
  console.log("I am doing something");
}

module.exports = doSomething

文件 B:

// b.js

doSomething();
// Exception - attempt to call a non-existent function

文件 C:

// c.js
var doSomething = require('a');
doSomething();
// logs "I am doing something"

在没有模块作用域的浏览器中， a.js将使用 doSomething 函数扩大全局范围，因为它被声明为全局。 Browserify 通过将每个捆绑的模块包装到一个函数包装器中来解决这个问题，并为包含的模块提供一个“导出”对象作为该包装器的参数。

输入 AngularJS。你有两种方法可以在这里使用，我假设你没有使用 require('angular') 是第一种:

在经过 Browserify 转译的捆绑脚本之前，将 AngularJS 作为硬编码脚本包含在 index.html 中。

Shim AngularJS 使其附加到导出对象而不是窗口(使用类似 browserify-shim 的东西)，然后像任何其他模块一样使用 require 导入它。

我更喜欢第二种方法，因为使用 Browserify 为您提供模块范围然后使项目的主要依赖项成为全局窗口有点奇怪。

然而，AngularJS 已经有了自己的依赖注入(inject)驱动的模块系统。当您声明 angularJS 组件时，您将它们附加到模块对象上，这些模块对象本身已附加到 angular目的。这意味着 exports在 Angular 的情况下，你的 angularJS 模块文件的对象本质上是多余的，因为只要文件执行， angular对象将使用您的模块和组件进行扩充。

您仍然需要“要求”这些文件，否则 Browserify 将不会捆绑它们，它们将永远不会执行，并且它们永远不会增加 angular对象与您的模块。但是您不需要为 Angular 的导出添加任何内容，因为 angular对象是您的导出。

那么为什么我要花这么多时间来解释 CommonJS 模块和导出是如何工作的呢？因为希望您使用 Browserify 的另一个原因是允许您在浏览器应用程序中使用托管在 NPM 上的模块。这些模块中的大多数都是非 Angular 的 commonJS 模块，这意味着它们的功能通过导出公开。在这种情况下，当您需要它们时，将它们的导出捕获到一个变量中很重要，例如我在 c.js 中所做的。多于。同样，如果您编写一些模块并将它们发布到 NPM，您的用户会期望您将模块的入口点添加到 exports在您的 package.json 中声明为 main 的文件的对象.