这是我参与更文挑战的第18天,活动详情查看:更文挑战
需求:
多个项目共用公共模块和组件。
场景:
- A项目使用公共组件B;
- A项目有需求改造组件B;
- C项目同时依赖B, 可能需要同步升级,也可能暂时不升级。
现状:
目前使用的是通过cnpm搭建的私有npm。
前期需要运维配置服务器和端口、开发人员本地配置hosts。
使用私有包:
登录私有npm,设置scope,安装
$ cnpm login
$ cnpm set registry http://npm.xxx.xxx:7001
$ cnpm login —registry http://npm.xxx.xxx:7001 —scope=@f2e
$ cnpm install @f2e/test
复制代码
开发私有包:
- 进入包目录开发、编译;
- 配置package.json;
- 添加发布源、登录、发布
$ npm adduser —registry=http://npm.xxx.xx:7001 —scope=@f2e
$ npm login —registry=http://npm.xxx.xx:7001 —scope=@f2e
$ npm publish
复制代码
优点:
- 标准化的包管理,版本概念较强,会习惯按照版本需求来开发,功能清晰;
- 多个项目通过版本号来选择对应版本,精准控制版本,互不干扰;
- 有专门的cnpm页面查看包信息(但缺乏维护约等于废弃状态)
缺点:
-
本地配置麻烦;
-
迭代流程复杂:
例如A项目依赖B组件,A项目的业务需求要求改造B,目前的开发模式是:
1. 在A项目中安装B 2. 进入A/node_moudles/@f2e/test 把文件夹拷贝到项目里,调试开发 3. 编译B 4. 使用cnpm登录发布 5. A项目更新B组件 复制代码
-
以上B包流程没有git管理;
-
包发布目前用的统一账户,无法查看是谁发布和修改的版本。
预期可优化方向:
- 使用git管理私有包项目
- 使用jenkins编译发布
另一个方案:
不使用cnpm管理包,单纯使用git + npm link 来实现管理公共依赖。
步骤:
- 建立一个组件git项目B;
- 在A项目中指定B的安装源为git
A项目使用方法:
直接安装对应git及版本(支持tag / branch / commit / semver)
注: semver即语义化版本控制规范,采用X.Y.Z的版本格式,支持alpha、beta等定义,可以使用特殊规范来标记版本号范围(同npm使用方法一致)。
例如
- 兼容模块新发布的补丁版本:~16.2.0、16.2.x、16.2
- 兼容模块新发布的小版本、补丁版本:^16.2.0、16.x、16
- 兼容模块新发布的大版本、小版本、补丁版本:*、x
由于git其实并不像npm有版本发布的概念,所以此处指定的版本其实是通过寻找tags
和refs
来完成的。
<semver>
can be any valid semver range or exact version, and npm will look for anytags
orrefs
matching that range in the remote repository, much as it would for a registry dependency.
npm install git+https://xxx.com/private-package.git#v1.0.0
// 或在package.json中指定:
"B": "git+ssh://git@gitxxxx:org/private-package.git#branch"
复制代码
B组件开发:
直接在B项目下开发,并提交git
AB调试:
-
使用npm link实现本地开发调试
-
进入B项目:
npm link
-
进入A项目:
npm link B
此时代码无需修改,package.json 中引用B的包会自动指向本地B的打包文件
-
调试完成后
npm unlink B
,B A 项目分别提交和发布
优点:
- 无需依赖服务器及各项本地配置,上手简单;
- git管理项目,简单清晰,便于查看版本;
- npm link 无须安装和提交代码,便于本地频繁调试;
缺点:
- 以提交为颗粒度,没有强化版本概念,需要开发人员手动通过标准化的tag来维护;
- 各版本功能没有清晰展示的地方(可以使用git的tag列表来查看,但信息量少);