带有 CommonJS 和 Browserify 的主干应用答案

【问题标题】：Backbone app with CommonJS and Browserify带有 CommonJS 和 Browserify 的主干应用
【发布时间】：2013-07-16 07:42:36
【问题描述】：

我正在考虑将我现有的应用程序转为使用 CommonJS 模块并使用 Browserify 将 bundle 模块合并到一个文件中。

我正在考虑编写模块，但在我开始重新编写某些位之前，我有点怀疑，我如何才能稍微优化它，这样我就不必包含 Backbone , Underscore, jQuery and any helper files in in each file, ie.

var Backbone = require('/backbone');
var $ = require('/jquery');
var _ = require('/underscore');

一段时间后，每个文件的顶部都会变得有点乏味。

作为一个完整的 CommonJS，Browserify n00b，我想知道我是否在某处遗漏了一些非常明显的东西？

【问题讨论】：

我认为除了公认的答案之外，另一个明显的事情是大多数人确实在需要的地方需要模块。这是需求模式的重要组成部分，恕我直言。也许乏味，但它不仅仅是样板；它清楚地说明了给定模块所依赖的其他代码片段以及该代码所在的位置，并有助于保持代码的模块化和独立性。它尽可能远离经典的 PHP 地狱，通过文件试图找到你知道来自 somewhere 的神奇函数定义。
commonjs 模块的核心原则之一是每个模块都明确标记其依赖项。保存击键，IMO，绝不是使用全局变量的好理由。

标签： backbone.js commonjs browserify

【解决方案1】：

您缺少的“非常明显的事情”是您可以在 Node.js 中创建全局变量，在 Browserify 环境中也是如此。要么通过使用global.Backbone = require('/backbone') 明确地做到这一点，要么通过使用Backbone = require('/backbone') 来减少明确性（前面没有var）。

请注意，在浏览器中，global 对象实际上是window 对象。但是，附加到 window 对象意味着您将失去与 Node.js 的兼容性，因为它通常没有定义全局变量 window。

【讨论】：

这就是我所做的。考虑到我们使用 Browserify 之类的工具来管理依赖项，这感觉有点不对劲，但只要你保持良好的组织并限制对全局变量的依赖，这真的很好。
虽然理论上是正确的，但我投了反对票，因为您不应该鼓励使用全局变量来节省击键次数。这个答案打破了 commonjs 规范的核心原则之一，即每个模块都应该明确定义其依赖关系。