搭建前端私有npm杂记

随着前端队伍越来越壮大,项目间共享代码就变得尤为重要。常用的框架/类库没必要在每个项目都放一份,团队内部产出的公共模块也需要有合理的共享机制。现在,用npm管理前端代码已经是业界趋势。楼主尝试用私有npm+资源管理系统的方式搭建起一套前端资源仓库,用以在公司内部托管公共代码,并为开发环境提供代码源。本文记录一下搭建过程,或许可以给大家做个参考。

整体架构

搭建私有npm的话其实是非常简单的,github上有一个叫做sinopia(https://github.com/rlidwka/sinopia)的项目,使用相当简单,无需配置数据库。用阿里的cnpm也是可以搭建私有npm的,不过配置稍微麻烦些。鉴于只是beta阶段,所以我就先采用简单的sinopia了。npm有两个作用:1.托管公共代码;2.为开发环境提供代码源。也就是说在开发环境,只需npm install,相应的代码就被下载到项目中。当然我们应该配置ignore,使得node_modules文件夹不被提交到代码库。线上的资源都是走cdn的。

光是私有npm还是不够的,考虑到公司不断有新的前端入职,有些还是新手,所以有必要为每个模块提供详细的说明。包括不限于基本信息、使用方法、在线demo、cdn地址等等。使用README.md文件虽然也能描述很多信息,但它只是一个静态文件,我们的系统还需要具备发布到npm、同步到cdn的功能。以后也可能进行功能扩充,比如为前端工程化提供支持。所以还需要一个资源管理系统,这个系统用于维护公共资源的各种信息。

所以,这么考虑下来,我们的前端资源仓库应该包含两部分:资源管理系统、私有npm。各自的功能如下:

搭建前端私有npm杂记

资源仓库的维护

所谓维护就是把源代码录入到资源管理系统、发布到npm、同步到cdn这一过程。按照npm的规格来组织模块的目录结构,但也不完全一致,因为有些是不需要的。模块都用UMD格式包装,这样无论用加载器还是直接写<script>标签都是可用的。具体格式如下:

  1. 用模块的名称命名根目录

  2. 模块的不同版本,新建不同的目录,如jquery/1.8.3/src/jquery.js,jquery/2.1.0/src/jquery.js

  3. src目录,用于放置未压缩的源码

  4. dist目录,用于放置压缩后的代码

  5. 使用package.json文件的规格来描述本模块

这样就够了,系统提供发布功能,上传的文件会自动发布到我们的npm,并且同步到cdn。至于模块的使用方法等其他信息,则需要模块维护者手动录入到系统中。这样,私有npm与这个资源管理系统就没有任何耦合,将来也好做扩展。流程如下:

搭建前端私有npm杂记

关于cdn的同步,我们只同步dist目录下的文件,因为线上只需要压缩版。至于模块的打包,不在本系统的职责范围内,由项目内的构建程序去完成。

如何使用

对于使用者,也就是前端同事们,需要做这么几件事:

  1. 项目中配置好package.json,npm install安装好所需的模块

  2. 从资源管理系统中获取到各模块的cdn地址

  3. 配置项目中的各模块地址,开发环境请求本地node_modules下的文件,线上环境请求cdn。

  4. 使用gulp进行相关的构建,发布到测试环境/线上环境

搭建前端私有npm杂记

在npm install前,需要把仓库地址指向我们搭的私有npm,而不再是npm官方的地址。使用npm set resigtry命令。如果你觉得麻烦,或者需要经常改动地址,github上有一个很方便的registry管理工具,nrm(https://github.com/Pana/nrm),推荐使用。

第3步需要做一个说明,因为我们现在项目很多,各项目的目录结构也不一致,有的前后端还未分离,所以无法做到用同一套构建程序搞定所有的项目。配置的方法视项目的情况而定,可以依靠后端来动态给require.config赋值,也可以用gulp来进行编译,总之能达到在不同环境请求不同路径就行。

技术细节

sinopia的话照着文档去安装就行。因为我们是安装在服务器上,所以有两点配置需要注意:

  1. node_modules/sinopia/conf下的default.yaml中,listen: - 0.0.0.0:4873,使得其他机器可以访问到该端口

  2. 在sinopia的存储目录下,有一个config.yaml,把proxy: npmjs注掉。我们公司内部可能只维护几个特定版本,所以没必要和官方仓库同步。

sinopia有一个机制,当你从私有npm安装一个模块时,如果不存在,会从npm官方仓库拉取,也就是这个proxy配置的地址。我们注掉后,也就无法去官方仓库去拉了,而这正是我需要的。一方面通过一个代理去访问npm有不稳定的风险,另一方面,我需要使用者时刻清楚,自己安装的模块是哪个仓库的。

至于资源管理系统的开发,后端使用nodejs、express,mongodb数据库,前端使用mvvm框架,还用了一个叫semantic的UI框架。基本就是对资源的增删改查操作,基本也没什么难度 。资源包含的字段如下:

搭建前端私有npm杂记

其中,类别暂时分为三类:

  1. 框架/类库。已经成熟的框架/类库,基本不会修改其代码,如jquery、requirejs

  2. 第三方组件。UI组件及功能组件,来自于第三方,不像框架那样稳定且有长期维护,例如:datepicker、弹框插件

  3. 自研模块。公司内部自己写的模块,通用的业务模块、功能模块

关于发布npm。在系统中上传源码的zip文件,先进行解压,然后使用了nodejs的child_process模块用来执行npm install命令,代码片段如下:

var exec = require('child_process').exec;
exec('npm publish '+targetPath, function (error, stdout, stderr) {
if (error !== null) {
console.log('exec error: ' + error);
res.json({success: false, message: error});
}
res.json({success: true, message: {name: filePath} });
});

至于cdn的同步,请到了我们运维同学的帮忙,我只要把文件上传至相关目录即可,后面的操作由他来搞~。

至此,我们的前端资源仓库就搭建起来了,服务器上使用pm2来管理,把sinopia和资源管理系统的server.js起来就可以了。

搭建前端私有npm杂记

总结

搭建这个项目其实难度并不大,但由于是抽空闲时间来搞,前前后后花了两个月时间。主要是花在系统的设计上。目前还是beta版,陆续会更新内容,先运行起来让同事们尝尝,估计会有大量的建议和问题,后面再做升级吧。各位朋友有任何建议,也可以给我留言,不甚感激。最后,截图来晒一下吧:

搭建前端私有npm杂记

注:本篇博客的微信公众号转发唯一授权给前端早读课,其他微信公众号不得转发,否则将受到侵权投诉。

上一篇:复习:IPC机制


下一篇:mysql函数count(*)和count(column)的区别(转)