阅读 161

npm私有模块方案评估

这是我参与更文挑战的第18天,活动详情查看:更文挑战


需求:

多个项目共用公共模块和组件。

场景:

  1. A项目使用公共组件B;
  2. A项目有需求改造组件B;
  3. 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
复制代码

开发私有包:

  1. 进入包目录开发、编译;
  2. 配置package.json;
  3. 添加发布源、登录、发布
$ npm adduser —registry=http://npm.xxx.xx:7001 —scope=@f2e  
$ npm login —registry=http://npm.xxx.xx:7001 —scope=@f2e  
$ npm publish
复制代码

优点:

  1. 标准化的包管理,版本概念较强,会习惯按照版本需求来开发,功能清晰;
  2. 多个项目通过版本号来选择对应版本,精准控制版本,互不干扰;
  3. 有专门的cnpm页面查看包信息(但缺乏维护约等于废弃状态)

缺点:

  1. 本地配置麻烦;

  2. 迭代流程复杂:

    例如A项目依赖B组件,A项目的业务需求要求改造B,目前的开发模式是:

     1. 在A项目中安装B
    
     2. 进入A/node_moudles/@f2e/test   把文件夹拷贝到项目里,调试开发
    
     3. 编译B
    
     4. 使用cnpm登录发布
    
     5. A项目更新B组件
    复制代码
  3. 以上B包流程没有git管理;

  4. 包发布目前用的统一账户,无法查看是谁发布和修改的版本。

预期可优化方向:

  1. 使用git管理私有包项目
  2. 使用jenkins编译发布

另一个方案:

不使用cnpm管理包,单纯使用git + npm link 来实现管理公共依赖。

步骤:

  1. 建立一个组件git项目B;
  2. 在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有版本发布的概念,所以此处指定的版本其实是通过寻找tagsrefs来完成的。

<semver> can be any valid semver range or exact version, and npm will look for any tags or refs 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调试:

  1. 使用npm link实现本地开发调试

  2. 进入B项目: npm link

  3. 进入A项目: npm link B

    此时代码无需修改,package.json 中引用B的包会自动指向本地B的打包文件

  4. 调试完成后npm unlink B,B A 项目分别提交和发布

优点:

  1. 无需依赖服务器及各项本地配置,上手简单;
  2. git管理项目,简单清晰,便于查看版本;
  3. npm link 无须安装和提交代码,便于本地频繁调试;

缺点:

  1. 以提交为颗粒度,没有强化版本概念,需要开发人员手动通过标准化的tag来维护;
  2. 各版本功能没有清晰展示的地方(可以使用git的tag列表来查看,但信息量少);
文章分类
前端
文章标签