前端应用能从 Node.js 学到什么

Will Binns-Smith 是一位热爱 JavaScript 的全栈工程师，喜欢通过技术来解决实际问题。他开发了 Bonobos.com 的前端购物车功能。Will 喜欢与设计师一对一工作，将 PC 网站转换为针对更小的触摸设备的站点。近日，Will 撰写了一篇文章，谈到了Node.js 有哪些做法和特性值得前端应用学习。

在 Web 平台能从 Node.js 学到什么这篇文章中，我们探索了由开发者为开发者所创建的小范围抽象所带来的好处。在这篇文章中，我们来了解如何以及为何应该将这种开发风格引入到你自己的 Web 前端中。

选择你自己的方式

作为小模块的用户，如果你不接受依赖所做的变动，那么你可以换另一个依赖。也许应用会使用某个模块的新版本（比如说 2.x），而应用的另一个依赖使用的却是老版本（比如说 1.x）。在 Node 中，由于依赖的查找是从邻近的 node_modules 目录开始，然后沿着文件系统逐级向上，即便需要不同版本号的相同模块，这种方式也是可以满足需求的。如果版本匹配，那么只会使用一个副本。

浏览器中的 npm 模块？这难道不是 Node 的事情？

你可能想知道如何能在不使用成百上千个 script 标签或是不在 RequireJS 配置文件中使用那么多条目的情况下维护如此多的依赖。也许你还想知道如何在浏览器中使用来自于 npm 的模块轻松创建 SVG 元素。诸如 Browserify 与 Webpack 等现代工具让这件事成为了可能，他们会通过 Node 所用的相同的 CommonJS require 语句来追踪应用的依赖图。他们使得一个大型包文件中的模块彼此可见，而你在页面中则可以通过单个 script 标签将其引入进来。

另一个常见问题就是这么做会不会增加向浏览器传送的 JavaScript 文件大小。在新版的 npm 中，这种模块树采用了扁平形式，同时又会向应用中的每个依赖提供所需的版本。借助于这种方式，你不会传递任何不需要的库的副本，同时又能满足每个模块的要求。此外，还有一个名为 rollup 的更加新颖的包管理器，它使用了 ES2015 模块格式，只打包你所导入的模块的子集。

我所认识的很多人都对将多个 jQuery 版本放到浏览器中这个想法感到惊讶。没错，这么做确实有些恐怖，虽然做了精简与 gzip 压缩，但 jQuery 依然会有 30KB 的大小。不过，传输 2 个、3 个、甚至 4 个 2KB 大小的库的副本相比起来却是微不足道的，特别是这么做能够避免手工解析依赖和升级 jQuery 以及安装的那些插件。即便如此，你也只应该在应用中包含了很多模块，并且这些模块又依赖于很多不兼容模块的情况下才这么做，因为 npm 3 在默认情况下会尽可能打平模块目录。你可以通过简单的安装随意使用 npm 注册的 100,000 多个模块。

界限在哪里

我们先来了解一些术语：包指的是可以发布到 npm 注册中心或是通过 git 仓库使用的单元。不过在 CommonJS 中，模块与文件是一一对应的。因此，一个包可以包含多个模块，不过通常情况下，一个 npm 包本身就是一个模块。

定义包的职责是最困难的一件事。如果包的范围过大，那么就会出现破坏性的改变，其后果就是破坏了生态圈。与之类似，如果一个包有很多依赖，那么破坏性的改变与 Bug 就会导致整个系统出现级联更新，无论开源还是内部使用都是如此。在设计包的范围时，一个好的原则就是软件组件的内聚性 %E3%80%82%E6%9C%AC%E8%B4%A8%E4%B8%8A%EF%BC%8C%E5%A6%82%E6%9E%9C%E5%87%A0%E4%B8%AA%E7%BB%84%E4%BB%B6%E4%BC%9A%E4%B8%80%E5%90%8C%E5%8F%98%E5%8C%96%EF%BC%8C%E9%82%A3%E4%B9%88%E4%BB%96%E4%BB%AC%E5%B0%B1%E5%BA%94%E8%AF%A5%E5%B1%9E%E4%BA%8E%E5%90%8C%E4%B8%80%E4%B8%AA%E5%8C%85%E3%80%82%E5%A6%82%E6%9E%9C%E4%B8%8D%E6%98%AF%EF%BC%8C%E9%82%A3%E5%B0%B1%E8%AF%B7%E6%8A%BD%E5%8F%96%E5%87%BA%E6%9D%A5%EF%BC%81">https://en.wikipedia.org/wiki/Cohesion_(computer_science)。本质上，如果几个组件会一同变化，那么他们就应该属于同一个包。如果不是，那就请抽取出来！

请记住，借助于 npm 与大多数包管理器，一个包不一定需要一个专门的仓库。如果过多的 Pull Request 的负担阻碍了发布新模块的流程，那就请考虑创建新的仓库，同时发布每一个包。Babel 是个开源的 JavaScript 编译器，它通过这种方式在单个仓库中维护了 100 多个包，极大地提升了效率，同时又将每个包发布到了 npm 中。

值得注意的是，Bower（另一个 JavaScript 包管理器）的一个限制是它使用 Git 仓库（或是 tarballs）作为接收模块代码的方式，因此它需要为每个包都创建一个仓库。我的建议则是使用 npm 。

尝试

通过小模块来构建应用要比你想象的简单多了。你的应用可能已经有了很多抽象，确定哪些抽象应该拥有自己的包其实是个很困难的事情。首先，如果只抽象了平台，并且提供通用目的的门面，那么最好提供一个开源的包。诸如 GitHub 与 Bitbucket 等服务都非常适合于这一点，如果使用的是 Node 或是浏览器，那么你当然应该将自己的工作成果发布到 npm 注册中心了。当然，其他语言的生态圈也拥有自己的包管理解决方案。

如果应用为内部业务逻辑提供了可重用的抽象，比如说对内部服务或是 API 的包装器，那么组织中的其他人就会从独立的包中获益匪浅。在 Atlassian，我们有很多小型的 JavaScript 客户端来访问报表或是分析等服务。此外，还有一个通用目的的包，它用于在新产品中快速开始 Atlassian Connect 的实现。对于源代码管理来说，我的建议是不要以每个仓库作为基础，这样才能创建出由很多小模块所构成的内部生态圈。Bitbucket Cloud 与 Bitbucket Server 都可以随着团队规模的变化而水平扩展。在发布包时，npm 在其云服务上提供了私有模块，并且提供了自托管的服务，从而作为源代码仓库管理的一个有益补充。你甚至还可以通过 Bitbucket Cloud 仓库来方便地安装 npm 模块：只需执行命令 npm install bitbucket:user/repo 即可。

一旦拥有了很多小模块，你就可以对其设计进行迭代，将其组合起来构建出更高层次的抽象。你可以无所畏惧地破坏 APIs，因为现代工具与语义化版本可以确保消费者能够从中作出选择，所有一切都会快速演进。这才是变化的真正意义。