标签:客户 管理员 包名 init lis 友好 -- 地址 访问
为什么要建立私有npm
- 提高代码复用程度,增加团队沉淀
- 剥离项目依赖,工程更加轻量
- 引用全量更新,支持版本降级
- 建立模块文档,降低上手难度
- 全员把关代码质量,无需重复测试
- 构建工具已成趋势,优化发布流程,减少手动工作,提高团队效率
- 增强团队代码交流
- 内部保密机制
要做的工作
- 搭建私有 npm 环境
- 探索 npm 使用工作流
- npm 对接 OA,做好权限控制
- npm 上传规范制定
- 现有组件上传 npm 要做的改造
- 使用 git 维护源码库
- git 与 npm publish 联动,实现自动测试、构建、发布、回滚
基于cnpm的私有npm搭建
为什么选择 cnpm?
- taobao 出品,经过大流量考验
- 国内大多数公司部署私有 npm 的选择
- 完整接口,减低二次开发难度
- 部署友好,支持 msyql,数据迁移方便
- 较为完善的 markdown 支持,文档友好
- 完善客户端支持,丰富的工作流选项
- 实际上没有很多别的解决方案,官方工具需要使用 coachDB,sinopia 过于迷你,没有数据库支持,且对 markdown 支持不好
部署过程
// TODO
// 其实已经搭建好了,超简单,有时间把详细过程下来:>
遇到问题
- 需要定义公司前缀,对项目侵入较大,使用了私有 npm 的项目必须使用 cnpm 安装,或指定 registry 安装,这就导致公共模块的包也会向私有 npm 请求,私有 npm 再从 taobao 源请求,可能会导致一定的延迟
- 需要在配置中指定管理员用户, 只有管理员用户才能 publish 项目,需要探索一下是否能够接入 oa 验证
- 默认界面太丑,可以优化一下,打上我们自己的标记
私有npm使用工作流
使用私有 npm 的几种方式
npm 有一个叫做 registry(源) 的配置项,类似于 linux 中的软件源的概念,这项配置指定 npm 应该以哪个地址为远程仓库,有了远程仓库,npm 才能够下载、发布这些代码。
所以,要使用私有 npm,就在于改变这个 regisitry 配置项,npm 为我们提供了两种方式来改变(也可能有多种,我常使用的就如下两种):
- 直接修改 npm 全局配置,如下:
npm config set registry http://npm.corp.chinahr.com
这样的好处是一次修改,永久使用,不需要再次设置,缺点是,这个地址并不是随时随地可以访问,因为是公司内网地址,对开发者侵入较大。
- 在每次执行 npm 命令的时候,后面加上
--registry
参数。
npm install vue --registry http://npm.corp.chinahr.com
这样做的好处是比较灵活,可以随意指定 registry 地址,并且本次生效,缺点是每次都需要手动输入 registry 地址。
所以这两种都不是完美的方案,cnpm 也提供了另外两种方案:
- 安装 cnpm 客户端(也是个 npm 程序),这个客户端包含了 npm 所有的命令,将这个客户端的 registry 设置为私有 npm 的地址,以后使用 cnpm 进行代替。
- 设置一个 alias 新命令,将私有 npm 的 registry 设置为默认,以后使用这个 alias 代替 npm 详细设置方法。
这四方法都可以使用使用 私有 npm,每个方法的缺点是:
- 对开发环境侵入较大,如果没有公司内网环境,则无法使用 npm, 需要切换回来;
- 使用繁琐;
- 新引入一个命令,无法和现有脚手架和自动化工具融合,其实 2 也有类似问题;
- 同 3,而且对 windows 系统不友好。
所以还是并没有什么完美的解决方案,最推荐的方案是 3
在以后的文档说明中,cnpm
命令即代表正确地使用私有 npm
下载 package
和 npm install 没什么区别,只是需要在包名前面加上公司前缀 @chr/
,这是因为 cnpm 的定位是一个 npm 镜像的全量同步工具,这样设置是防止与npmjs.org 中的 package 发生冲突
例如:私有 npm 中有一个叫做 webpack 的包,下载的时候需要这样:
cnpm install @chr/webpack
发布 package
发布 package 需要预先在配置文件中授权,这个等到咱们的 oa 接入了, 就可以配置好权限,做到所有人都可以发布。
发布 package 的步骤:
- cnpm init
在这个模块下创建 package.json,让这个文件夹下的文件受 npm 管理,注意项目名称前应该加上@chr/
- 完善文档信息
修改项目的 README 文件,对项目做一个简要的说明
- 完善版本号
如果是初次发布的项目,版本号无需处理,如果是对项目进行更新,则应该先修改版本号,否则无法发布
- cnpm login
在命令行中登陆 npm,这个后期会和 oa 进行联动,现在的状态是,如果没有用户会自动注册,这里建议使用 oa 账号,方便以后对接。
5. cnpm publish
发布 package
待解决的问题
- npm 会自动安装最新版本的 package,如果某个 package 版本更新通知没有做到位,可能会导致接口升级导致的现有代码受影响的情况
发布 package规范
搭建私有npm 最大的意义就是能够复用我们核心代码,提高开发效率,所以对上传上来的代码要有一个严格的规范,这样能够保证代码质量,减少沟通成本,防止协作的时候产生混乱。
这个规范需要一起来讨论制定,我先把我想到的几点写出来,大家一起完善
文档对于模块化项目来说十分重要,通过文档,调用者能够对项目的基本功能一目了然,迅速了解这个项目解决了什么问题、如何调用、存在什么问题,而不需要去与项目的维护者进行沟通。
npm 有默认的 package 自文档管理方案,即通过项目内的 README.md
项目文档应该至少包含以下几个方面:
- 解决了什么问题
- 包含那些组件
- 如何调用
- 有哪些配置项
- 存在哪些问题
- 更新计划: 长期/快速迭代
example
应该包含其中项目中各个方法的示例程序
测试
作为基础模块,单元测试必不可少,基础模块也很适合做单元测试
测试这块,我没有什么经验,大家可以一起探索
review
重要模块的更新及上线,应该由团队大多数人进行 review
npm script
更新通知
私有npm计划
标签:客户 管理员 包名 init lis 友好 -- 地址 访问
原文地址:http://www.cnblogs.com/coder-zyz/p/6748654.html