前端包管理器争端,只不过是构建工具的牙缝菜

前端的争端越来越多,就像如今这个创业当职业的社会一样,一个工具出来,还没有成熟,它的替代品就已经抢占风头,比如grunt和gulp,比如npm和yarn,各个公司都有自己的风格,发布自己的工具,吸取前人的成果,实现自己的抱负。前端包管理器也是争端不断,虽然npm大有一统天下的趋势,但是非常明显,npm的模式非常容易复制,yarn只需要做更多的宣传推广工作,完全就可以取代它。实际上,作为开发者,往往希望一个稳定的工具,同时又可以在它基础上不断发展,用自己想用,避自己想避。

前端包管理器的主要目的,是为了解决包依赖问题。这里面涉及一些概念,一个一个阐述。

包管理器及其江湖

所谓包管理器,就是一个可以对开发者发布的包进行管理的工具而已,评判这个工具的好坏,应该是以这个工具能否解决对应的管理问题,而非网上很多人讨论的社区、托管平台等一系列附加问题。

目前比较流行的有npm, bower, component等,我看了下知乎,国内还可推荐有spm3,其他的管理器知名度不大,或许还处于公司内部自己好用的层面。facebook的东西给我感觉总是带着公司内部需求的设计,比如react native和yarn,感觉都是它公司内的产品需求衍生的项目,结果后来没有上线产品,或者自己玩着觉得爽,就发布出来。但是不管怎么样,我的理念是:有更多的选择总是好事,物要各尽其能。这一点上我喜欢gulp插件建议里面写的,说“一个插件只做一件事,不要做别人已经做过的重复的事,或者不要做几件事,拆分开就可以了”。一个东西完成一件事,不一定需要天天更新版本,能在关键位置物尽其能就好。

所以我不希望看到npm一统天下的局面,不过从现在前端的发展来看,一统天下几乎是不可能的,没有哪家公司只用某一个公司的产品或者把命根寄托在一个东西上。npm和bower我接触的比较多,所以就发表一下对他们的看法。

npm最令我欣喜的功能,是它的script功能,相反,它的树状依赖结构我并不喜欢,虽然它这样可以很好的解决依赖版本问题。对于一个项目而言,同时依赖多个版本,意味着要把这几个版本都打包进去,这就可能会产生冲突,比如大家都挂了一个属性在window上。但是npm实际更多的是承担node的模块管理,而非前端包管理。在node的代码里,require的时候路径不一样,引用的模块也不一样,而且每一次require的时候,都会去执行,并不是说你前面require了,后面require同一个东西就直接读内存里上次require的,所以当某个包依赖一个低版本的包时,并不影响其他依赖相同包但版本更高的情况。可是运行在浏览器端的情况完全不同,jquery多个版本一起运行时,后面的方法会把前面的覆盖掉,window上绑定的东西,会在第二次jquery加载时替换掉。所以这个版本不可能像node那样树状结构。

而bower则是基于这种思想,即你依赖的包,必须选出一个来用,如果库里面有多个版本,你依赖的包里也有不同包依赖不同版本的情况,那么bower甚至会强制你选择其中一个版本来用。这种情况下,如果高版本的包对低版本不具备兼容性,那么那个依赖低版本的包,就会出现问题。一旦出现这种问题,作为开发者是没有办法解决的,除非去改bower包的源码,让包依赖高版本。当然,不会有人去这样做。

包≠组件

我要推的,是组件的概念。我们传统意义的前端是在浏览器端滚动的关注html, css, js的开发,而现在的前端,其实最终也是要回到浏览器,只不过开发模式已经更新了一个世纪。趴在桌子上盯着屏幕一个像素一个像素的调样式的前端还在努力,这部分人并没有减少,传统的写好html、css、js的工作模式仍然在很多公司流行。即使在这个层面的前端工作里,也有非常多新奇的想法,比如前后端分离,模块化等等,他们并没有构建工具,但仍然不亦乐乎。但是,当前端程序员开始使用构建工具的时候,前端猿类就开始向前端人类进化,使用工具让现在的前端跟以前的前端工作模式完全不同,现在讨论包管理器、构建工具远超出单点技术的探讨。

而组件,就是在构建工具出现之后被迫提升的。在以前的前端开发中,我们听到更多的是“插件”,一个好的插件,就像一个非常好的黑箱,有良好可控的接口,实现漂亮的功能。使用npm和bower的起初,会误以为这中东西,无非是把插件统一管理起来,可以一下子下载到自己本地使用,这样的想法不止我一个人有过。

包并不一定是黑箱,它还有可能是锤子,是工具,比如underscore,你说它是插件,可是它没有非常明确的要实现什么功能,特别是在浏览器界面效果上,啥功能?类似的很多包,它们更多的是提供算法,或优化服务。所以npm对应的是package.json,它可以管理包,而这些包,更多的是为node提供特定的功能,别人写好的功能,你直接require进来,就可以用,很爽。

不过在浏览器端还有一种情况,就是它仅实现某些效果的特定部分,比如渐隐渐现,你也可以把它做成一个插件,用的时候调用接口。但是,如果你使用构建工具来build代码,你很难说这个插件什么时候用,要不要包含在你最终的代码里面。就举个简单的例子,你可以说slider是一个插件,但是slider里面有一个功能是touch slide,我只需要这个功能在我的代码里,是否可以把这部分代码独立出来,你slider也可以用,我自己的代码里面也可以用?这个功能就是一个独立的未被构建的包,就是我所说的组件。

组件的特征有两点:1. 没有被构建,也就是说肯定会被别人require进去,别人在build时候才用你;2. 功能独立,模块小,复用和扩展都很方便。

在构建之前它叫组件,构建好之后,它就在你的产品里消失了。就拿上面那个touch slide的组件来说,在你做好自己的插件之前,它是独立存在的,被你require进来,但是当你build完自己的插件发布之后,你根本不需要告诉别人touch slide是什么,而只需要告诉别人怎么用你的插件。

npm的包天生是用来被require的,但是这些包大部分是运行在node环境里面,不需要构建过程,所以实际上也只是包,谈不上组件。而bower则是实实在在的组件,bower的specs里面说,bower.json is used for configuring packages that can be used as a dependency of another package,它们是用来build的时候的用的。所以包括bootstrap在内的一些遵守这个规则的bower component都是为别人构建做准备的。而像很多人想的那样,把dist目录下的build好的文件当做bower component的入口,其实是不对的。不过bower并未强行规定,这种误解导致bower饱受诟病。假如npm将来顶替bower在component上走上述老路的话,势必也会遇到相同的问题。

构建

由于这种误解把component的概念暴露的太过,以至于有些人试图回避component,直接将它隐含在构建过程中。前端大神TJ是componentjs的作者,componentjs的想法,是将component的管理,使用和构建统一于一体。你可以使用componentjs像bower一样从componentjs自己的库下载组件备用,还可以在开发完后自己做build。但随着webpack等工具的火热,componentjs停止维护了。维护者们发现webpack超级好,完全顶替了componentjs的很大一部分,所以就放弃了继续开发。

这里的componentjs和webpack就是构建工具,componentjs不能说是纯粹的构建工具,因为它最初其实是以包管理器的身份亮相的。

构建工具,也就是做build的工具,将你按照模块化组织好的代码,通过构建之后,得到非模块化的单一成品。这个成品可以是任何形式,比如是一个库或一个插件,也可以是一个新的组件。

构建是现代化前端的必要过程,也得益于此,html, css, js再次被大整个,这并不是倒退,在开发过程中,他们还是分开的,只不过在最终的结果中,它们表现为杂糅在一起。特别是angular, react这样的库,它们上来就要求js和html的杂糅。

接下来要讨论的,是component和构建的关系。在构建中,任何一个被引入进来的包,都应该被称为组件,因为在最终的结果中,你并不需要将使用了哪些组件暴露出来。构建出来一个插件就是一个插件,构建出来一个应用就是一个应用。

构建工具超级杂乱,几乎所有的公司都有自己的构建工具,webpack只是其中最优秀的一只。之所以这么乱,是因为构建没有规范,大家都在讨论哪个build工具,打包工具好用,却并不打算推行构建工具遵循的原则。而webpack也更愿意把自己定位为一个工具,而非规范的构建者,这也会导致后来必定有新工具代替它。但若它建立了一套规范,那么后来者只会完善它,而不会想再造轮子。也正因没有大家公认的规范,一旦一个工具退隐,所有以往通过该工具构建的应用,就不能不面临升级问题,因为按照该工具的规则进行构建而写的代码,在后来新用的工具中不兼容。比如之前用component构建,现在用webpack就得想办法使之兼容。

构建工具有简单也有复杂,复杂如webpack,简单如babel,babel一个命令把你之前用es6写的代码转换为es5,但不会打乱原来的代码组织结构。用grunt gulp之类的流程管理工具配合一些插件,也可以生产出自己的构建工具,比如gulp-uglify gulp-sass gulp-cssmin等插件,都是为我们构建服务的。正是这种便捷性,我也开发了自己的构建工具componer,而本文就是在写componer的过程中思考而写的。

以组件为包的构建原则

在npm和bower的体系里,大家把重点争论放在谁解决依赖性问题更好一点,都说bower过时了,这些论断都是从一些侧面去说的,比如bower都没人维护了,说明它过时了,或者说看到bower和npm上都可以下载类似jQuery这样的库,感觉也就是个插件托管器,没啥特别。这些说法都没有抓住实质,bower的包目录名是bower_components,npm的包目录名是node_modules,这其实已经非常说明问题了。component和module在一些方面是有些重合的,但是显然,module并不需要用来build,而component这个词本身就意味着应该用来build。

还有一个问题,就是为什么要有包管理器,如果仅仅是个托管服务或者插件下载器,那确实没啥用,但是它要解决依赖问题。非常哲学的思考是,为什么它要解决依赖问题?因为它要为build做准备,只有在考虑build的时候才需要解决依赖问题,不build,不需要思考这个问题。在bower和npm之间,npm其实是一种回避式的解决问题方式,因为npm是树状结构的依赖关系,也就是说同一个组件可以在目录里有很多很多份,主要看它的主版本是不是内部模块依赖的。但是bower就不同,它要求你自己决定使用哪一个版本,这种管理是主动出击式的,但是问题就是对于开发者而已,又更加麻烦了,而且有的时候这个依赖问题本来就不好解决。所以就目前而言,npm确实比bower更加优越的解决了依赖问题。但是同样的,有优势就会有代价,代价就是在做build的时候,相同代码可能会被使用多次,导致最终结果的代码冗余。

解决这个问题,其实应该回到组件本身。以jQuery为例,jQuery一次性将自己所有模块都放在自己的源码里,开发者一旦依赖于前一个版本,就会把它打包到自己的应用中,但是如果应用中的其他组件依赖高版本,那么就不得不面临两个选择,一个是手动解决依赖,另一个是把两个版本都打包进去。就npm体系而言,后者是常见的选择。因此,对于组件本身而言,最好在版本之间做出一个抉择,把大组件拆分为小组件,build过程中尽量不依赖版本,而只需要知道是不是需要这个组件而已。因此,在componer.json中,我根本不会要求开发者填写dependences的版本号。从这点上,我follow的,是bower的包管理思想。

一个component不应该自己执行某些动作,比如在window上挂载一些方法。组件应该在被require之后再去被调用。以jQuery为例,不应该在内部已经在window上挂好$,应该在代码中require后使用。但是这给测试带来了一些问题,测试需要写更多实现代码。但我认为这无可厚非。

目前而言,webpack和npm基本上是一家,它们联合起来,给build埋下了我上文提到的这些坑,webpack如果用在build应用的时候,往往会在不同模块之间共享一个同名模块,但如果一旦这个模块被依赖的版本不同,那么就坑了。

以组件为包的思想,我更赞赏bower,因为它在specs里写的非常清楚,main这个字段就是为了build做为入口的文件列表。

除了保持这种为了build而制作组件的思想外,我觉得组件还应该具备两个基础特征:1. 封闭性。组件虽然给外面去做build,但内部应该极其稳定,不受到任何外部变量的影响,无论你外部怎么运行,遇到什么bug,跟我组件没有半毛关系。2. 扩展性。组件意味着提供特定的接口给外部使用,对于外部的使用者而言,组件可能满足了大部分需求外,却又少数一些情况无法满足,需要开发者在组件基础上进行扩展,或者写个方法进行覆盖。所以以class的形式写组件比较好,这样可以使用extends对它进行扩展。

组件的依赖应该写在dependencies里面,但是不应该把依赖代码build进组件的最终成品中去,这样非常不友好。component本身是提供build素材的,而非plugin提供直接使用的成品。说到这里,需要补充一下,bower中使用一个component的时候,并不应该直接在浏览器里面引用它,包括jQuery和bootstrap这两个非常流行的库,在bower中,它们是component,而不应该直接在浏览器中使用script或link引入到页面中。但是在测试的时候,依赖又必须被使用,这就麻烦了,如果所有的依赖和你的组件都是遵循一个构建规则还好办,把依赖包们都用同样的构建工具build好,再引入即可,抑或测试的时候把test目标文件作为app整个build出来。我个人推荐第二种,把test当做一个实例化的app来跑。但是如果你依赖的组件构建规则跟你正在使用的工具不同,那么就麻烦了,你没法直接build它们。所以,不管你用什么工具,一个相对统一的构建规则在这里极其重要。

这个统一的规则第一条就是“入口文件”和“模块化规范”。

构建规则

入门文件,就是你在做build的时候,构建工具以哪一个文件作为entrypoint,一般会在这个文件中import或require组件内的其他文件,最终提供对外的统一接口。对于js而言,使用webpack打包,可以在js里面直接require样式、字体、图片等文件,这非常棒,使得一个组件的静态资源可以直接作为变量放到内存中,但代价就是组件会消耗比较多的内存,以至于浏览器崩溃。

package.json中的main只能是字符串,一般而言应该只能使用js,因为require是为了加载模块而诞生的,诞生webpack把它扩展了。对于webpack而言,package.json中的main字段没有意义,你需要自己给webpack的配置项entry中传入自定义的入口文件。诞生对于bower而言,他们则不这么想。bower.json中的main字段就是规定入口文件的。所以对于bower而言,它并不限定你遵循什么模块化规范,它让你暴露你的入口文件,这样你的构建工具就会顺着入口文件,把你的所有代码都build到自己的产品中。

但是你会发现,你怎么知道bower component内部是以什么方式相互引用的呢?虽然我们想象中大部分情况都是采用require,但是说实话,这并不确定,我遇到过并不是用require的情况,他们在window上注册了一个特定的属性,然后提供一些方法,特别是register方法,这样内部的小模块都可以注册到这个属性中,整个组件就依靠这个属性实现相互引用。这种情况你该怎么办?目前我还没有看到一个可以通过window中的某个属性找到对应的文件的build工具。所以说,这种对modules规范不加规定的敞开式原则,会导致非常严重的兼容性问题。bower的这一点饱受诟病,或许是因为Twitter没有发布一个构建工具来解决这个问题而导致的,但也很可能是因为他们确实就看到了,构建这种工具可能根本是不可能的。

不知道你读到这里的时候有没有感觉到一点,就是“bower因为没有解决其modules的build工具而逐渐被开发者抛弃,相反,npm因为有webpack的强力支撑而大行其道”。是的,没有构建工具支撑的包管理器注定会遇到障碍,因为这里面的本质原因是,包管理器是为构建提供素材(组件)的,也就是说,没有一个构建工具使用包管理器管理的包,那么它的这些包都是一些没有用的资源。

CommonJS在server端被广泛使用,而浏览器端AMD则是一种解决方案。ES6绕过了这两种相对成熟的模块化规范,标准开发者们相信,有更加高效的modules解决方案。而在ES标准中,require还是没有被囊括,这说明他们不承认CommonJS的成就,认为它可能只是个临时的解决方案,一旦未来所有环境支持ES6的modules,那么CommonJS的历史使命就结束了,那个时候,如果webpack和npm还在的话,不得不面临一个重大问题:是升级后兼容老的CommonJS,还是被新的支持ES6 modules的新包管理器及构建工具代替,最终退出历史舞台。一旦在这条路上走的越远,最终的结果往往是后者。

我理想中的包及构建应该是怎样的?首先,component应该有怎样的入口,依赖应该怎么定义,内部应该遵循什么模块化规范,应该怎么构建和发布?其次,用这些component的构建工具,应该怎样使用它们的入口文件,如何组织单个组件和组件群的依赖,输出的结果应该遵循什么原则?最后,作为component的开发者和作为使用component的开发者各自应该注意些什么?

先解决component的内部矛盾。

我认为bower式的入口指定非常好,这种思想让component本身的定位非常清晰,就是为了给别人build的,所以只需要提供入口文件,包括js和scss/less,甚至不需要bundle,只需要源码。依赖问题上,我也更倾向于bower这种扁平的结构,树状结构确实很好可以解决版本问题,但是往往只有扁平结构才能降低代码重复率和文件大小问题,而且版本问题其实是一个隐性问题,我认为一个组件升级到一个大版本,应该是以新的组件出现,就像docker的image一样,是单独的,而非对上一个版本的覆盖,用户可以自己选择用哪一个版本,或者两个一起用,但是不应该强迫一起用。bower比较坑的地方是没有规定component内部应该遵循什么模块化规则,对我而言,目前我所遵循的模块化规范只有ES6开始的import/export规范。由于这是标准,不同的建构工具可以自己去写解析器,比如babel可以解析为require/module.exports,未来一定会有构建工具直接支持标准,目前来看,只有babel可以解析,但大部分构建工具都可以支持babel插件。

组件本身可能也需要构建,但是也可以不用构建,如果内部遵循的规范和外部使用的构建工具遵循的规范一致,就可以不用,比如component内部使用require,那么webpack就可以直接使用它。我觉得UMD也是一个可选的方案,component内部全部采用UMD实现模块间的引用,那么在外部工具去使用component时,只要能够支持UMD所支持的其中一种模式,都可以搞定component。

一旦遵循了这些原则,使用bower比使用npm更符合我们的预期。毕竟npm还是更适合做一个更加稳定和优化的node模块管理器。

再说说构建工具(builder)。

这里我又要重新提到componentjs,因为它是最早拥有构建component思想的工具。当你使用componentjs的时候,首先要从它的registry下载组件,下载下来的组件总是拥有component.json,这个文件里我们主要讨论dependencies(依赖)、templates(html模板,可以是handlebars这样的模板)、scripts(脚本,可以是js,或者coffee之类的)、styles(可以是css,也可以是scss、less之类的)。这几个字段非常好的给定了入口和依赖,比如脚本的入口,没有styles这个字段就表示没有样式入口。在bower中直接使用一个main字段把后三者全部囊括进去这反而感觉不是太好,分开可能更清晰的指出我们想要的。

接下来是依赖问题。

前面提过了,component内部是不包含依赖的,这也就是说必须由构建工具来决定依赖是否应该打包进bundle,以及以什么形式。这一点webpack就很好,所有的依赖不会出现第二次,代码重复率很低,除非有人故意将代码放在component里面。bower这种扁平化的结构,相对来说更好解决依赖问题,因为路径非常明确,也没有版本衍生问题。

当构建工具在面对依赖时,应该考虑一个问题,你的构建结果是什么?如果是package,那就是要复合commonjs,如果还是一个component,那就应该符合上面我所说的一个component的特征,而如何是一个plugin,那就按插件的形式来好了,如果是一个库就应该提供不同情况下的不同版本,而如果是一个完整的应用呢?那就应该提供一个在浏览器端完整执行的bundle文件。

所以,实际上,对于构建工具而言,更难搭建。如果不带着解决某类问题去开发一个构建工具,而是想搞一个大而全通用性极强的构建工具,会考虑一大堆不同情况,而且性能还很差。构建工具的两端,一端是组件,但是组件像上文指出的那样,各自不同,builder应该规定一种规范或者兼容性规则,而在另一端,则是产品,也是形式多种多样。我更喜欢那种专注一种的,componentjs就很好,送入的是component,出来的也是component。而相对而言,webpack更像是打包一个SPA类型的应用。

gulp其实是一个基础的构建工具框架,它只是提供了管道,一端进一端出,基于gulp可以开发自己的构建工具,在管道中搞定自己想要的功能。

结语

这篇文章没想到写那么多,这仅是我在开发componer过程中的一些想法。componer就是遵循上述规则的构建工具,它其实也是输入component输出component的工具,输入的和bower包很像,所有输出的component遵循同一套规则,从而保证使用它们的framework只要接受这些规则,就可以直接使用它们。

最后,包管理器的争端真的没有必要,因为真正有价值值得完善的,是构建工具。

2016-12-21 | , , ,

已有1条评论
  1. […] 前端包管理器争端,只不过是构建工具的牙缝菜 […]