为什么不将它用作 Javascript 的通用组件模式，包括浏览器执行的 Javascript？
乍一看，这似乎是一种将我目前正在从事的项目模块化的好方法，该项目由一个大型 Javascript 代码库和许多组件组成，其中一些组件相互交互。
【问题讨论】：
标签： javascript architecture components design-patterns commonjs
CommonJS 绝对适合浏览器，但有一些注意事项。 CommonJS 模块模式非常好（在我看来是有偏见的），它也是为 ECMAScript Harmony（计划中的 JavaScript 语言的下一个版本）提出的模块系统的一个很好的垫脚石。具体来说，Harmony 模块无法访问全局（“窗口”）对象。
有些人声称 CommonJS 模块不适合浏览器的原因是，如果没有服务器端的帮助，它们就无法通过
var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
// do something then call convertToHTML
}
这不能通过脚本标签起作用，原因有几个（范围没有被包装，所以 convertToHTML 会附加到窗口，通常不会定义 require 并且需要为每个模块单独创建导出） .
带有少量服务器端帮助的客户端库可以允许通过脚本标签轻松加载。或者，通过 XMLHttpRequest 加载脚本并执行 eval() 的客户端库也可以工作，尽管调试体验通常不那么好。
目前一个相当合理的解决方案是RequireJS，尽管它也是 CommonJS 成员之间争论不休的主题。使用 RequireJS，你可以这样编写你的模块：
define(function(require, exports, module) {
var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
// do something then call convertToHTML
}
});
我们所做的只是在模块周围添加了 define() 位。 （你也可以让服务器很容易地做到这一点，这样你甚至不需要手动输入定义部分）。
我现在在几个项目中亲自使用过 RequireJS，发现它是一种无需服务器端位即可使用 CommonJS 模块的简单方法。还有许多其他解决方案，如果您不依赖运行静态 JS 文件，标准 CommonJS 模块是一个不错的选择。
（ObDisclaimer：我启动了 CommonJS 项目，所以我显然有偏见。）
【讨论】：
define 和exports 变量，并有条件地检测两组代码。