sinopia服务
私有npm的优势
- 内网服务器安装依赖 妈妈再也不用担心GFW(
- 库代码的权限控制
- 与其它npm库相同的依赖方式, 减少学习成本. 无需使用gitsubmodule等方式
- 通过类似npm官网的网站一目了然公司使用的全部模块/版本
技术方案
sinopia: 搭建私有的npm服务, 它可以做到以下事情
- 上传/下载私有的npm库
- proxy机制, 非全量同步,本地未找到依赖自动去指定源下载, 然后缓存至sinopia/storage(可修改)
- 覆盖公有库, 方便的修改开源项目
- 自带前端管理网站
pm2: 强大的node.js命令行部署/托管工具
nrm: 方便的切换npm源的CLI工具
安装依赖
1 | npm install -g sinopia pm2 nrm |
开启sinopia
输入pm2 start sinopia开启服务
访问http://localhost:4873
看到这个页面即为搭建成功
配置sinopia
sinopia的目录位于你第一次执行开启命令的目录
- storage: 私有库存放地址
- htpasswd: 用户管理
- config.yaml: 配置文件
1 | storage: ./storage # npm包存放的路径 |
生产环境中的使用
容器部署
最佳实践是将sinopia作为单独服务部署在docker容器中
在此我制作了一个可以直接使用的docker image 启动容器则自动开启服务, pm2将会守护sinopia进程
版本控制
将sinopia作为公司内部npm库还存在几个问题
- 使用npm publish上传的流程无法统一管理, 也就是无法持续集成/code review
- 每个版本的更新信息完全依靠文档, 无法通过code diff追溯
以gitlab为例, 我的做法是
- 将ci runner的服务器切换至私有源, 使用npm adduser注册一个root用户
- 在sinopia服务器上将sinopia/config.yaml中的max-users设置为-1, 禁止注册与私自更新版本
- 将node库源代码在gitlab中创建项目 提交代码走PR流程
- ci.yml中, build环境处理lint, unit test, production build等流程,tag环境npm publish提交版本, 保持gitlab与npm版本一致
- 邮件通知各组成员 库版本更新信息
团队使用
团队所有成员切换npm至私有库
前面提到nrm库 可以方便的切换npm源
1 | nrm add private http://localhost:4873 # 添加源管理 |