这让人吃惊,让人有些生畏,JavaScript和它的工具的世界可以在转眼之间改变.但是,现在,npm和browserify让我们变得相当不错.我们拥有成千上万个有用的函数和模块,他们组合在一起,提升了Unix哲学的小巧和非耦合的工具,模糊了"浏览器"和"客户"的界限 (例如,查看headless-gl).并且,更惊奇的是,我们可以使用这些模块,而不用担心路径,版本地狱(version hell)或累赘的配置文件.

　　Webpack看起来像是很棒的工具,它有许多特性(模块热切换,代码拆分,同步对异步请求等).然而,它没有像NPM和Browserify所做的那样来提升代码重用.它鼓励用"完全新的方式"来编写模块,同时常常需要人工维护配置文件.这是一个根本性的退步:它可能在npm中产生更进一步的碎片化,或者可能阻碍新代码发布到npm中去.

　　为了解释其中的一些问题,可以将这个简单的例子内联一个JSON文件到浏览器中.

require函数的过度使用

　　用Webpack风格的方式来内联JSON文件,是使用一个加载器,像这样:

　　通常,我厌倦了require()的过度使用,这个函数在Node中有一个特殊的用途,改变它在以后可能导致疑惑和错误.但对于Webpack来说,它运行的相当好.另外,它有一些很好的特性,像释放图片到一个输出目录.

　　问题是,这个代码和Node和browserify不兼容,同时也不鼓励通过npm进行重用.对于Node和browerify用户来说,使用Webpack风格的require来编写模块,这将导致碎片化和不可避免的"分支和补丁(fork-and-patch)"的状况.

node使用

　　在Node 和browserify这样使用:

　　但是, Webpack 默认并不支持(或许永远不会), 所以在NPM 模块里你会看到很多 打破JSON规则的配置.

使用brfs

　　在Node/Browserify中,另一种常见的方式来解析JSON文件是使用fs.readFileSync和brfs转换.代码看起来像下面这样:

　　许多模块使用readFileSync来内联HTML和CSS(如soundcloud-badge),模板,GLSL和其它的文本文件到它们的集合.模块常常是和node兼容的: 例如,可参看browser-menu.

　　不幸的是,Webpack不能使用这些模块,除非你在配置中设置一个转换加载器(transform-loader) (当前在调试?).

　　如果你有一个巨大的Browserify模块的依赖树,可能很难知道正在使用哪个转换.同时,在Webpack配置文件中手动设置它们也是一件很繁琐的事情.如果这些依赖正在版本之间使用不同的转换参数,这也会成为一个严峻的考验.

包配置

　　Browserify的一个重要特性就是对多个依赖之间转换的处理方式. 比方说我已经在npm中 创建了一个叫做foo的模块，它实用类如上代码中的brfs. 我可以把brfs标记为一个依赖，并把它列在我的package.json中的 browserify-transform 下面.

　　然后，有些可以安装并 require('foo'), 再然后他们会加载主应用程序，它整个会“全部都运行起来”, browserify 将会知道要去使用 brfs 进行转换, 即使用户并没有明确的对它进行设置.

　　这样就可以让一个browserify构建对依赖进行正确的处理, 而不用去管你的依赖使用的是什么类型的转换.

　　Without this feature for如果Webpack中的 loaders/transforms 没有了这个特性, 代码的复用就将会陷入跨越多个使用了不懂装载器的依赖，这样的噩梦之中. 问题: #378.

最后的想法…

　　Webpack 仍然还只是一个年轻的工具; 真心希望这些问题能够得到解决，如此我们就不用浪费掉到目前为止我们在npm/browerify上所作出的非凡努力.

　　与此同时，我将继续坚守 browserify. :)