私有npm的优势
- 内网服务器安装依赖 妈妈再也不用担心GFW(
- 库代码的权限控制
- 与其它npm库相同的依赖方式, 减少学习成本. 无需使用
gitsubmodule
等方式 - 通过类似npm官网的网站一目了然公司使用的全部模块/版本
技术方案
sinopia: 搭建私有的npm服务, 它可以做到以下事情
- 上传/下载私有的npm库
- proxy机制, 非全量同步,本地未找到依赖自动去指定源下载, 然后缓存至
sinopia/storage
(可修改) - 覆盖公有库, 方便的修改开源项目
- 自带前端管理网站
pm2: 强大的node.js命令行部署/托管工具
nrm: 方便的切换npm源的CLI工具
安装依赖
npm install -g sinopia pm2 nrm
开启sinopia
输入pm2 start sinopia
开启服务
配置sinopia
sinopia的目录位于你第一次执行开启命令的目录
- storage: 私有库存放地址
- htpasswd: 用户管理
- config.yaml: 配置文件
storage: ./storage # npm包存放的路径
auth:
htpasswd:
file: ./htpasswd # 保存用户的账号密码等信息
max_users: -1 # 最大允许的用户数量,-1则为禁止注册
uplinks:
npmjs:
url: registry.npm.taobao.org # npm地址 当在本地服务找不到依赖时则会拉取这个源的npm库
packages: # 配置权限管理 所有用户有权限拉取项目 但是没有权限更新项目
'@*/*':
# scoped packages
access: $all
publish: $authenticated
'*':
access: $all
publish: $authenticated
proxy: npmjs
# log settings
logs:
- {type: stdout, format: pretty, level: http}
listen: 0.0.0.0:4873 # 默认没有,只能在本机访问,添加后可以通过外网访问。
生产环境中的使用
容器部署
最佳实践是将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源
nrm add private http://localhost:4873 # 添加源管理
nrm ls # 查看源列表
nrm use private # 切换至该源
npm install @scope/package-name@version --save-dev # 其它操作与npm公用库相同
网友评论