前端规范与思考(四)——npm规范

发表于 更新于

本文属于原创文章，转载请注明–来自桃源小盼的博客

前言

npm的部分，与团队自身的技术架构关系十分密切，不同的前端工程化方式，必然带来不同的开发体验。

所以本篇的内容，按需采纳才好。

使用相同的包管理工具及版本

为每个项目添加.nvmrc文件，并在package.json中增加engines。

有些团队里，可能同时使用了npm、yarn、cnpm、pnpm。

所有人都用同一个工具，出了问题，也能及时同步和互相帮助。

使用相同的npm源

为每个项目添加.npmrc文件

国内为了加速下载，一般是使用淘宝源。如果公司搭建了私有仓库，那么就用私有的。

注意：淘宝源最近更换了域名https://npmmirror.com/，检查一下老项目里的.npmrc文件。

公有库使用规范

仔细评估第三方库的情况

可以参照以下八个方面：

  • 功能是否符合
  • 性能
  • 包体积
  • 稳定性，是否还在维护中
  • 生态如何
  • 学习曲线难度
  • 作者是谁
  • 社区活跃度
  • 开源协议

每次选择一个新的三方库时，要多花点时间仔细评估，不要为了赶需求进度，而随便选一个。

软件开发是个长期行为，尤其库的更换成本更大，所以在这方面多花点时间，不是坏事，会为未来节省时间。

优先使用团队已选择的库

如果团队按照前一个规范来选择库，那么在未来就要优先使用已选的库。不要仅仅根据个人喜好和习惯来使用另一个库。

如果基础技术栈变更了，或者行业里有了更好的选择，或者上一次选择在很多年了。这时有必要重新评估，是继续沿用，还是统一替换，一般来说新项目使用新的选择更稳妥。

禁止忽略package-lock.json

我想很多人都经历过，突然有一天，项目就起不来了。就是因为某个库，做了破坏性的更新，第三方包如何管理版本号是不可控。

当然还有其他的版本管理措施，阅读依赖锁不锁。

使用npm cli命令管理包

不论新增和删除总是使用npm命令来管理。假如你想删除一个包，直接从package.json中手动删除了，那么package-lock是不会更新的。

定期升级node版本及相关依赖

一般node的一个版本维护周期是2.5年。查看这里

如今node的更新改动并不会很大，通常是新增api和提升性能，更新node版本一般都比较顺利。

定期关注核心依赖的更新情况，有利益减少bug或潜在风险。

不要使用在package.json中未声明的包

因为npm或yarn的目录拍平结构，你可以使用到依赖的依赖，这是不安全的做法。

只在开发中使用的包，将包声明到devDependencies中

私有库开发规范

一个团队，总有一些可以重复和提炼的东西，那么私有库就是最好的选择，如果将公司内部的代码，发布到公网，安全隐患很大。

包命名

@团队名/包名

例如：@itfe/mui

版本号

主版本号. 次版本号. 修订号

例如：1.9.1 -> 1.10.0 -> 1.11.0。

  • 主版本号(major)：当你做了不兼容的API 修改
  • 次版本号(minor)：当你做了向下兼容的功能性新增
  • 修订号(patch)：当你做了向下兼容的问题修复

其实整个npm社区，并没有完美遵循整个规范。但是我们私有包，一定要严格遵守。

在.npmigonre中忽略源码部分，只发布构建后的产物

有利于减少包的体积，加快下载速度

为包提供仓库地址

在readme中提供仓库地址，并在package.json中添加repository属性。

私有包的定制性通常较强，使用者可能会遇到各种问题，或者想提供新的特性。

给他们提供可以交流或联系的渠道是上佳选择。

参考资料