私有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

更新通知