你可能不知道的 npm 实用技巧

时间 2019-12-06

标签可能不知道 npm 实用技巧繁體版

原文原文链接

分享一些 npm 包管理工具的实用小窍门，但愿可以略微提升下前端、Node.js 开发者的生活质量。

绝大多数前端和 Node.js 开发者天天的平常工做都离不开 npm，不知道你对 npm 的观感如何？若是你以为 npm 很棒，那么不妨看下这篇文章，说不定其中有你以前没留意过的小窍门，可让你 npm 用得更顺手。若是你以为 npm 很糟糕，那也能够看下这篇文章，也许会发现用上一些小技巧，npm 会变得稍微不那么糟糕。node

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 也能够不那么慢。webpack

另外，若是 package-lock.json 过期（和 package.json 冲突），那么 npm ci 会很贴心地报错，避免项目依赖陷入过期状态。git

有了 npm ci，基本上我只在引入新依赖时才使用 npm install。程序员

注意，npm ci 在安装前会自动清除现存的 node_modules，因此 npm ci 自然规避了增量安装可能带来的不一致性等问题。（这也意味着，你又能够少记一条命令 npm prune。）不过，若是你的网络很慢，那可能就不那么妙了。别慌，你能够用 --prefer-offline，最大限度地利用 npm 的全局缓存加速安装过程。github

固然，既然使用 npm ci，那就别忘了把 package-lock.json 加入 git 仓库。web

npm outdated

npm ci 基于 package-lock.json 锁定依赖版本，确保项目开发环境的一致性。但这并不意味着依赖版本是锁死的。为了利用新版本带来的问题修复、新特性以及性能提高，按期仍是须要升级依赖版本的。在这一场景下，推荐使用 npm outdated。它会列出尚未升到当前最新版本的项目依赖。红色表示符合指定的语义化版本范围，理论上能够无脑升级（npm update 会一次性升级全部红色依赖）。黄色表示不符合指定的语义化版本范围，好比大版本升级，升级可能会遇到兼容性问题。npm

有些项目处于维护阶段，不打算加新特性了，甚至可能不太严重的问题都不打算修复了，可是像安全漏洞这样的严重问题仍是要管的。这时可使用 npm audit 命令，列出项目依赖中有安全漏洞的版本。处于活跃开发阶段的项目固然也须要关注安全漏洞问题，可是由于 npm install 引入新依赖时会自动运行 npm audit，再加上会按期运行 npm outdated，因此手动运行 npm audit 的机会不太多。json

npx

前面说过基本上只在引入新依赖时才使用 npm install，没有提到全局安装。全局安装固然也须要使用 npm install。不过，为了确保开发环境的一致性，npm install --global 应当慎用。我的建议仅仅在安装一些平常使用的工具时才使用全局安装，而项目开发所需的工具，则做为开发依赖安装，而后使用 npx 调用。缓存

不推荐：

npm install --global webpack
webpack ...

npm run

在 package.json 的 scripts 属性中加入命令（例如："foo": "echo foo"）就能够经过 npm run foo 运行对应命令。这是 npm 提供的一个很方便的运行项目相关的自动化任务的机制，有一点相似 make。不过直接运行 make （不带任何参数）会运行默认任务，但直接运行 npm run （不带任何参数）会列出全部在 scripts 中声明的命令。

; npm run
Lifecycle scripts included in leancloud-realtime:
  test
    npm run lint && npm run build && npm run docs && npm run test:node && npm run test:browser

available via `npm run-script`:
  precommit
    pretty-quick --staged
  commitmsg
    commitlint -e $GIT_PARAMS
  lint
    eslint --ignore-path .gitignore src test plugins && tsc realtime.d.ts --strict
  ...

其余

这里还有一些我我的以为不是特别实用的小窍门，不过，每一个人的需求和偏好不一样，说不定你会以为它们挺有用的。若是你有想要分享的窍门，欢迎留言。

npm init -y 默认状况下，npm init 会让你回答一些问题。npm init -y 能够跳过这些问题，直接上手开发。我之因此不推荐它，是由于，若是你打算尽快上手开发一个应用，绝大多数状况下会用框架，而几乎全部框架在 npmjs 上都至少有一个 create-xxx-app 包。因此基本上你没有机会输入 npm init 去回答那些问题。而若是你打算写一个组件或库，那么 package.json 中的元信息对组件或库的使用者很重要（即便是仅供你本身使用的组件或库，将来的你也未必记得当初写这个组件或库的上下文），跳过这些问题并非一个好主意。固然，急躁是程序员的三大美德，你也许会想，我能够在完成开发后再来补这些。可是，通常来讲，每每项目开始的时候是你最有兴趣（或者说，稍微不那么反感）记录这些上下文的时刻。若是在项目开始的时候都不耐烦作这个，开发完成后，极可能就更没兴趣了。同理，README 也应该在项目开始前写。
npm repo 能够打开项目的源代码仓库（大部分状况下是 GitHub），它还有一个姊妹命令，npm home，能够打开项目的主页。不过，我我的以为，比起这两个命令，一般而言， IDE 或者编辑器的智能提示（速览类型、速览文档、速览定义之类）更高效。
.npmignore 文件能够列出不想打包的文件，避免把一些无关的文件发布到 npmjs 上。可是，统一使用 .gitignore 能够知足绝大部分场景下的需求。并且，只存在 .gitignore 的状况下，npm publish 会尊重 .gitignore 的声明，而 .npmignore 和 .gitignore 同时存在的状况下，npm publish 会忽略 .gitignore，而不是取二者的并集。换言之，.gitignore 中忽略但 .npmignore 中未忽略的文件会被打包发布。因此，使用 .npmginore 就意味着须要同时当心翼翼地维护两份大部份内容重复的列表。同时，一旦团队中有任何一人由于偶然的疏忽或者不熟悉 .npmignore 和 .gitignore 关系的细节出现了失误，那就有可能将敏感信息发布到 npmjs 上，致使安全事故。
各类 npm 命令的快捷版本，好比上文用到的 npm i -D。这些我的以为不用专门刻意去记。常常输入的命令，能够 npm help 一下看看有没有简短版本。不查也没有关系，npm t 和 npm test 乃至 npm run test 的区别毫不是开发效率的瓶颈所在。不少时候这只是我的偏好问题，好比追求尽量少打字的人会喜欢 npm t，追求尽量少记东西的人会喜欢 npm run test （永远不会由于误觉得 npm build 表示 npm run build 而碰到问题），其余人可能会喜欢 npm test 这样中庸的选项。
npm xmas 猜猜输入这个命令会获得什么结果？你能够亲自试一下。提示：这个命令彻底没有实用性可言。;-)