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

前言

大多数前端和Node.js开发人员在日常工作中离不开npm。我想知道你对npm的看法。如果你觉得npm很棒，不妨看看这篇文章。也许有一些你以前没有注意到的技巧，可以让你更方便地使用npm。如果你觉得npm不好，也可以看看这篇文章，你可能会发现有了一些小技巧，npm会变得不那么坏。

npm ci

不要被它的名字所迷惑。Npm ci不仅适用于持续集成系统，而且在日常开发中非常实用。与npm install不同，npm ci根据package-lock.json安装依赖项，可以保证整个开发团队使用同版本的依赖项，避免浪费时间排查依赖项不一致导致的各种奇怪问题。此外，npm ci还有很好的副作用，加快了节点模块的安装速度。由于npm ci是根据package-lock.json中指定的版本直接安装的，所以不需要计算和解决依赖满足问题，在大多数情况下可以大大加快节点模块的安装过程。如果你曾经因为npm安装太慢而转到兼容性较差的纱线和兼容性较差的pnpm，不妨试试npm ci。也许你会发现NPM不能这么慢。

此外，如果package-lock.json过期(与package.json冲突)，npm ci将密切报告错误，以避免项目依赖关系陷入过期状态。

对于npm ci，基本上我只在引入新的依赖项时使用npm install。

请注意，npm ci会在安装前自动清除现有的node_modules，因此npm ci自然避免了增量安装带来的不一致性。(这也意味着你可以少记住一个命令，npm修剪。但是，如果你的网络很慢，可能就不太好了。不要惊慌，您可以使用-prefere-offline来最大限度地利用npm的全局缓存来加快安装过程。

当然，由于使用了npm ci，不要忘记将package-lock.json添加到git存储库中。

国家预防机制已经过时

Npm ci基于package-lock.json锁定依赖版本，确保项目开发环境的一致性。但这并不意味着依赖版本被锁定。为了利用新版本带来的问题修复、新功能和性能改进，有必要定期升级相关版本。在这种情况下，建议npm过时。它列出了尚未升级到最新版本的项目依赖项。红色表示符合指定的语义版本范围，理论上可以无脑升级(npm update会一次性升级所有红色依赖)。黄色表示不满足指定的语义版本范围，如大版本升级，可能会遇到兼容性问题。

有些项目处于维护阶段，所以不打算增加新的功能，即使是不太严重的问题也不打算修复，但是像安全漏洞这样严重的问题仍然需要管理。此时，您可以使用npm audit命令列出项目依赖关系中存在安全漏洞的版本。当然，处于主动开发阶段的项目也需要关注安全漏洞。但是，因为当npm安装引入新的依赖关系时npm审核将自动运行，并且npm过时将定期运行，所以手动运行npm审核的机会不多。

萘普生

如前所述，npm install基本上只在引入新的依赖项时使用，而没有提到全局安装。全局安装也需要npm安装。但是，为了确保开发环境的一致性，应该谨慎使用npm install - global。个人建议只在安装一些日常使用的工具时使用全局安装，而项目开发所需的工具则作为开发依赖项安装，然后由npx调用。

不推荐：

NPM安装-全球网络包网络包.推荐：

网络包.这里的id是install - save-dev的简称。

对于一些一次性的临时任务，可以通过npx直接运行相应的工具，避免了手动安装的麻烦，也不会污染devDependencies。

例如，在项目用webpack打包之前，现在我想暂时尝试一下使用汇总打包的效果：

Npx汇总.npx非常智能，如果在路径中找不到rollup，它将自动安装。

Npx对于测试不同版本的兼容性非常有用。这里有一些例子。

需要使用的cowsay的一个特性或修复已经集成到GitHub主线中，但是新版本还没有在npmjs上发布。试试看：

npx github : piuccio/co say临时测量内部维护的co say分支：

nbxgitsh ://my . hosted . git 3360 cow say . git # semver : 1当前正在使用LTS版本(10)的节点。我想看看节点12下的构建脚本是否可以运行：

NPX-p[email protected]npm Run Build从上面我们可以看到，当包名和命令名不同时(NPM命令由node提供)，可以用-p选项指定包名。

npm运行

向package.json的scripts属性添加一个命令(例如，“foo”:“echo foo”)，可以通过npm run foo运行相应的命令。这是npm提供的一种方便的机制，用于运行与项目相关的自动化任务，类似于make。但是，直接运行make(没有任何参数)将运行默认任务，但是直接运行npm run(没有任何参数)将列出脚本中声明的所有命令。

；包含在leancloud-realtime:测试中的npm runLifecycle脚本NPM run lint NPM run build NPM run docs NPM run test : node NPM run test : browse Ravailable via ` NPM run-script ` : precommit漂亮-快速阶段提交msg commit lint-e $ git _ paramslint eslint-ignore-path。git忽略src测试插件TSC实时.

这里有一些我个人认为不是特别实用的小技巧。然而，每个人的需求和偏好是不同的，所以你可能会发现它们很有用。如果你有什么小技巧可以分享，请留言。

Npm init -y默认情况下，Npm init会让你回答一些问题。Npm init -y可以跳过这些问题，直接开发。之所以不推荐，是因为，如果你打算尽快开发一个应用，那么大多数情况下都会用到框架，而且几乎所有的框架在npmjs上都至少有一个create-xxx-app包。所以基本上你没有机会进入npm init来回答这些问题。而且如果你打算写一个组件或者库，package.json中的元信息对于组件或者库的用户来说是非常重要的(即使只是自己使用，你可能也不记得以后写这个组件或者库的上下文)，所以跳过这些问题不是一个好主意。当然，不耐烦是程序员的三大美德，你可能认为我可以在开发完成后弥补。然而，一般来说，一个项目的开始是你对记录这些背景最感兴趣(或稍微不那么反感)的时刻。如果你在项目开始时就迫不及待地想这样做，那么在开发完成后，你可能会更不感兴趣。同样，README应该在项目开始之前编写。Nmprepo可以打开项目的源代码仓库(大多数情况下是GitHub)，它还有一个姊妹命令，npm home，可以打开项目的主页。但是，我个人认为与这两个命令相比，IDE或编辑器的智能提示(快速查看类型、快速查看文档、快速查看定义等。)通常效率更高。那个。npmignore文件可以列出您不想打包的文件，并避免向npmjs发布不相关的文件。然而，使用。gitignore统一可以满足大多数场景的需求。此外，NPM出版将尊重的声明。仅当。gitignore存在，而NPM出版将忽略。当两者都存在时，gitignore，而不是取它们的并集。换句话说，文件在。gitignore，但在中未被忽略。npmignore将被打包并发布。因此，使用。npmginore意味着同时仔细维护两个内容重复的列表。同时，一旦团队中的任何一个人因为意外疏忽或不熟悉关系的细节而犯错。npmignore和。gitignore，有可能向npmjs发布敏感信息，导致安全事故。各种npm命令的快捷版本，如上面使用的npm i -D。这些人觉得不需要特别记住。对于经常输入的命令，您可以在npm帮助中查看是否有短版本。不查也没关系。npm测试与npm测试甚至npm运行测试的区别绝不是开发效率的瓶颈。很多时候，这只是个人喜好的问题。比如想尽可能少打字的人会喜欢npm t，想尽可能少记忆的人会喜欢npm run test(他们永远不会遇到问题，因为他们误以为npm build就是npm run build)，还有人可能会喜欢npm test这种中等选项。Npm xmas，猜猜如果输入这个命令会发生什么。你可以自己试试。提示：这个命令一点实用性都没有。-)摘要

以上就是本文的全部内容。希望本文的内容对大家的学习或工作有一定的参考价值。谢谢你的支持。