npm 中的前端打包有哪些痛点？

　　我们已经知道前端资产和依赖管理是 npm 的一个巨大用例，也是 Node.js 采用的主要驱动力。 但究竟有多大? 这是一个很难回答的问题。 npm 上下载最多的包列表并不是很有帮助：像 async、minimist 和 request 这样的包是依赖于成千上万个其他包的基本包，所以它们当然会一直安装和下载 作为这些软件包安装的一部分。

　　那么，说到前端包，摩擦在哪里?

　　前端痛点

　　1. node_modules 没有按照前端包需要的方式排列

　　这是一个非常明显的问题。 node_modules 文件夹是 npm 默认放置包的位置，以利用 Node.js 模块加载语义。根据你安装的软件包，软件包最终位于树中的不同位置。这对 Node 来说很有效，但是 HTML 和 CSS，无论好坏，通常都希望东西在一个位置，比如 /static/mypackage。可以肯定的是，有一些解决方法，但还没有一流的解决方案。

　　2. 前端依赖有不同的冲突解决需求

　　Node 模块加载器的乐趣之一是它允许你同时存在同一个模块的多个不兼容的版本，而 npm 的乐趣之一是它将这些版本放在正确的位置，以便你期望的版本会加载到你期望的位置。这对消除“依赖地狱”大有帮助，也是 Node 的“许多小模块”模式如此实用和受欢迎的原因之一。

　　但是前端依赖项根本无法以这种方式工作。如果你加载两个版本的 jQuery，一个会“获胜”。如果你加载两个版本的 Bootstrap CSS 框架，它们将同时应用并破坏你的样式。未来，Web 组件和 Shadow DOM 等 HTML 的新发展可能有助于解决这些问题，但目前，前端依赖关系可能会发生冲突，我们如何识别和优雅地处理它?

 

　　3. 维护多个包清单很烦人

　　前面问题的解决方案一直是为前端包创建额外的注册中心，但这造成了单个项目必须有一个package.json、一个bower.json、一个component.json等等的情况，并且每次发生小更新时都编辑它们，像所有数据重复一样，这既繁琐又容易出错。

　　4. 寻找与浏览器兼容的包是件痛苦的事

　　npm 是 JavaScript 的注册表，但目前注册表中的大部分内容是 Node.js。其中一些模块适用于使用诸如 browserify 之类的模块的客户端时可以工作，但其中一些则不能。目前，如果不尝试它们，就无法轻松找出哪些可以，哪些不可以。