前言
绝大多数前端和 Node.js 开发者每天的日常工作都离不开 npm,不知道你对 npm 的观感如何?如果你觉得 npm 很棒,那么不妨看下这篇文章,说不定其中有你之前没留意过的小窍门,可以让你 npm 用得更顺手。如果你觉得 npm 很糟糕,那也可以看下这篇文章,也许会发现用上一些小技巧,npm 会变得稍微不那么糟糕。
npm ci
别被它的名字骗了。npm ci 并不仅仅适用于持续集成系统,在日常开发中,npm ci 非常实用。和 npm install 不同,npm ci 根据 package-lock.json 安装依赖,这可以保证整个开发团队都使用版本完全一致的依赖,避免把时间浪费在排查因为依赖不一致而导致的各种奇怪问题上。不仅如此,npm ci 还有一个很好的副作用,加快 node 模块安装速度。因为 npm ci 直接根据 package-lock.json 中指定的版本安装,无需计算求解依赖满足问题,在大多数情况下都可以大大加速 node 模块安装过程。如果你曾经因为嫌 npm install 太慢而换用兼容性不那么好的 yarn 以及兼容性更不好的 pnpm,那么不妨试下 npm ci,也许你会发现,其实 npm 也可以不那么慢。
另外,如果 package-lock.json 过时(和 package.json 冲突),那么 npm ci 会很贴心地报错,避免项目依赖陷入过时状态。
有了 npm ci,基本上我只在引入新依赖时才使用 npm install。
注意,npm ci 在安装前会自动清除现存的 node_modules,所以 npm ci 天然规避了增量安装可能带来的不一致性等问题。(这也意味着,你又可以少记一条命令 npm prune。)不过,如果你的网络很慢,那可能就不那么妙了。别慌,你可以用 --prefer-offline,最大限度地利用 npm 的全局缓存加速安装过程。
当然,既然使用 npm ci,那就别忘了把 package-lock.json 加入 git 仓库。
npm outdated
npm ci 基于 package-lock.json 锁定依赖版本,确保项目开发环境的一致性。但这并不意味着依赖版本是锁死的。为了利用新版本带来的问题修复、新特性以及性能提升,定期还是需要升级依赖版本的。在这一场景下,推荐使用 npm outdated。它会列出还没有升到当前最新版本的项目依赖。红色表示符合指定的语义化版本范围,理论上可以无脑升级(npm update 会一次性升级所有红色依赖)。黄色表示不符合指定的语义化版本范围,比如大版本升级,升级可能会遇到兼容性问题。
新闻热点
疑难解答
图片精选