4

我一直在追赶现代客户端 JS 生态系统，并阅读了 CommonJS 和 AMD 等模块系统（包括相关工具 - browserify、requirejs、onejs、jam，以及其他许多工具）。如果我正在编写一个 Javascript 库，我如何打包它以使其可以被最广泛地访问（理想情况下是那些对 CommonJS、AMD 尤其是两者都发誓的用户）？

像 jQuery 这样的流行库似乎只是使用老式文件连接来构建自身并动态检测它是否应该写入导出或全局上下文。我目前正在做同样的事情，但主要的缺点是如果我（与 jQuery 不同）依赖于一些库，那么不必要求用户手动预包含传递集是很好的。（虽然我目前只有两个依赖项。）当然还有全局命名空间污染。

或者，为每个上下文生成多个版本的库可能是最干净的？

这也会影响包装和出版。有几个系统，但我相信主要的一个是 bower，它很容易处理，因为它所做的只是获取。但是，如果我想将其打包成组件，则需要一个 CommonJS 模块。

还有其他我应该注意的相关方面吗？对于所有这些，是否有任何好的示例项目可以遵循？

4

1 回答 1

3

我自己一直在思考这个问题，我得出了几个结论：

  1. 创建一个可用于全局和 AMD 设置的框架版本
  2. 不要沉迷于必须要求您的客户手动包含依赖项，这是一个每个项目的活动，无论如何都应该完成，无论您提供 AMD 打包的框架还是全局范围的框架（第 3 方依赖项放置必须无论如何都要调整，这就是我的意思）
  3. 我使用 Grunt 进行项目构建/打包/测试/linting/whatever，因此对于所有其他打包替代方案，我有不同的任务。

因此，简而言之，首先为“old-school/AMD”构建，然后为“new-age”打包。

附言

我也坚信您的打包和交付流程/需求不应该（尽可能）决定您的架构和开发决策。

我尝试构建最可定制、模块化和可用的代码，同时使用我选择的打包范例，然后我考虑替代打包。如果我在第一部分成功了，第二部分通常要么是直接的，要么只需要很少的代码库更改（因为第一步中的模块化和适当的原则应用）。

于 2013-05-18T05:16:27.660 回答