私有npm计划

 

为什么要建立私有npm

1. 提高代码复用程度，增加团队沉淀
2. 剥离项目依赖，工程更加轻量
3. 引用全量更新，支持版本降级
4. 建立模块文档，降低上手难度
5. 全员把关代码质量，无需重复测试
6. 构建工具已成趋势，优化发布流程，减少手动工作，提高团队效率
7. 增强团队代码交流
8. 内部保密机制

要做的工作

1. 搭建私有 npm 环境
2. 探索 npm 使用工作流
3. npm 对接 OA，做好权限控制
4. npm 上传规范制定
5. 现有组件上传 npm 要做的改造
6. 使用 git 维护源码库
7. git 与 npm publish 联动，实现自动测试、构建、发布、回滚

 

基于cnpm的私有npm搭建

为什么选择 cnpm?

1. taobao 出品，经过大流量考验
2. 国内大多数公司部署私有 npm 的选择
3. 完整接口，减低二次开发难度
4. 部署友好，支持 msyql，数据迁移方便
5. 较为完善的 markdown 支持，文档友好
6. 完善客户端支持，丰富的工作流选项
7. 实际上没有很多别的解决方案，官方工具需要使用 coachDB，sinopia 过于迷你，没有数据库支持，且对 markdown 支持不好

部署过程

// TODO 
//　其实已经搭建好了，超简单，有时间把详细过程下来:>

遇到问题

1. 需要定义公司前缀，对项目侵入较大，使用了私有 npm 的项目必须使用 cnpm 安装，或指定 registry 安装，这就导致公共模块的包也会向私有 npm 请求，私有 npm 再从 taobao 源请求，可能会导致一定的延迟
2. 需要在配置中指定管理员用户， 只有管理员用户才能 publish 项目，需要探索一下是否能够接入 oa 验证
3. 默认界面太丑，可以优化一下，打上我们自己的标记

私有npm使用工作流

使用私有 npm 的几种方式

npm 有一个叫做 registry(源) 的配置项，类似于 linux 中的软件源的概念，这项配置指定 npm 应该以哪个地址为远程仓库，有了远程仓库，npm 才能够下载、发布这些代码。

所以，要使用私有 npm，就在于改变这个 regisitry 配置项，npm 为我们提供了两种方式来改变(也可能有多种，我常使用的就如下两种)：

1. 直接修改 npm 全局配置，如下：

1. npm config set registry http://npm.corp.chinahr.com

这样的好处是一次修改，永久使用，不需要再次设置，缺点是，这个地址并不是随时随地可以访问，因为是公司内网地址，对开发者侵入较大。

1. 在每次执行 npm 命令的时候，后面加上 --registry 参数。

1. npm install vue --registry http://npm.corp.chinahr.com

这样做的好处是比较灵活，可以随意指定 registry 地址，并且本次生效，缺点是每次都需要手动输入 registry 地址。

所以这两种都不是完美的方案，cnpm 也提供了另外两种方案：

1. 安装 cnpm 客户端(也是个 npm 程序)，这个客户端包含了 npm 所有的命令，将这个客户端的 registry 设置为私有 npm 的地址，以后使用 cnpm 进行代替。
2. 设置一个 alias 新命令，将私有 npm 的 registry 设置为默认，以后使用这个 alias 代替 npm 详细设置方法。

这四方法都可以使用使用 私有 npm，每个方法的缺点是：

1. 对开发环境侵入较大，如果没有公司内网环境，则无法使用 npm， 需要切换回来；
2. 使用繁琐；
3. 新引入一个命令，无法和现有脚手架和自动化工具融合，其实 2 也有类似问题；
4. 同 3，而且对 windows 系统不友好。

所以还是并没有什么完美的解决方案，最推荐的方案是 3

在以后的文档说明中，cnpm　命令即代表正确地使用私有 npm

下载 package

和 npm install 没什么区别，只是需要在包名前面加上公司前缀 @chr/，这是因为 cnpm 的定位是一个 npm 镜像的全量同步工具，这样设置是防止与npmjs.org 中的 package 发生冲突 
例如：私有 npm 中有一个叫做 webpack 的包，下载的时候需要这样：

1. cnpm install @chr/webpack

发布 package

发布 package 需要预先在配置文件中授权，这个等到咱们的 oa 接入了， 就可以配置好权限，做到所有人都可以发布。 
发布 package 的步骤：

1. cnpm init　 
   在这个模块下创建 package.json，让这个文件夹下的文件受 npm 管理，注意项目名称前应该加上@chr/
2. 完善文档信息 
   修改项目的 README 文件，对项目做一个简要的说明
3. 完善版本号 
   如果是初次发布的项目，版本号无需处理，如果是对项目进行更新，则应该先修改版本号，否则无法发布
4. cnpm login 
   在命令行中登陆 npm，这个后期会和 oa 进行联动，现在的状态是，如果没有用户会自动注册，这里建议使用 oa 账号，方便以后对接。 
   5.　cnpm publish 
   　发布 package 
   　

待解决的问题

1. npm 会自动安装最新版本的 package，如果某个 package 版本更新通知没有做到位，可能会导致接口升级导致的现有代码受影响的情况

发布 package规范

搭建私有npm 最大的意义就是能够复用我们核心代码，提高开发效率，所以对上传上来的代码要有一个严格的规范，这样能够保证代码质量，减少沟通成本，防止协作的时候产生混乱。

这个规范需要一起来讨论制定，我先把我想到的几点写出来，大家一起完善

README.md

文档对于模块化项目来说十分重要，通过文档，调用者能够对项目的基本功能一目了然，迅速了解这个项目解决了什么问题、如何调用、存在什么问题，而不需要去与项目的维护者进行沟通。 
npm 有默认的 package 自文档管理方案，即通过项目内的 README.md 
项目文档应该至少包含以下几个方面：

1. 解决了什么问题
2. 包含那些组件
3. 如何调用
4. 有哪些配置项
5. 存在哪些问题
6. 更新计划: 长期/快速迭代

example

应该包含其中项目中各个方法的示例程序

测试

作为基础模块，单元测试必不可少，基础模块也很适合做单元测试

测试这块，我没有什么经验，大家可以一起探索

review

重要模块的更新及上线，应该由团队大多数人进行 review

npm script

更新通知