作者：LeanCloudweakish分享一些npm包管理工具的实用小技巧，希望能稍微提高前端和Node.js开发者的生活质量。绝大多数前端和Node.js开发者在日常工作中都离不开npm。你觉得npm怎么样？如果你觉得npm很棒，那么不妨看看这篇文章，或许其中有一些你之前没有注意到的小技巧，可以让你使用npm更加顺畅。如果你觉得npm很糟糕，你也可以阅读这篇文章，也许你会发现通过一些技巧，npm会变得稍微不那么糟糕。npmci不要被它的名字所迷惑。npmci不仅适用于持续集成系统，在日常开发中，npmci非常实用。与npminstall不同的是，npmci根据package-lock.json安装依赖，可以保证整个开发团队使用完全相同版本的依赖，避免因依赖不一致导致的各种奇怪问题浪费时间排查。不仅如此，npmci还具有加速节点模块安装的良好副作用。因为npmci直接按照package-lock.json中指定的版本安装，不需要计算和解决依赖满足问题，在大多数情况下可以大大加快node模块的安装过程。如果你曾经因为npminstall太慢而换过兼容性差的yarn和兼容性更差的pnpm，不妨试试npmci，说不定你会发现npm其实可以没那么慢。另外，如果package-lock.json过时（与package.json冲突），那么npmci会很贴心的报错，防止项目依赖陷入过时状态。使用npmci，基本上我只在引入新依赖项时使用npminstall。注意npmci在安装前会自动清除已有的node_modules，所以npmci自然避免了增量安装可能带来的不一致等问题。（这也意味着少了一个需要记住的npmprune命令。）但是，如果你的网络速度很慢，那可能就没那么好了。不要惊慌，你可以使用--prefer-offline来最大限度地利用npm的全局缓存来加快安装过程。当然，既然你使用了npmci，那么不要忘记将package-lock.json添加到git仓库中。npmoutdatednpmci根据package-lock.json锁定依赖版本，保证项目开发环境的一致性。但这并不意味着依赖版本陷入僵局。为了利用新版本带来的错误修复、新特性和性能提升，仍然需要定期升级依赖版本。在这种情况下，建议使用npmoutdated。它将列出尚未更新到最新版本的项目依赖项。红色表示满足指定的语义版本范围，理论上可以不假思索升级（npmupdate会一次性升级所有红色依赖）。黄色表示不符合指定的语义版本范围，比如大版本升级，升级可能会遇到兼容性问题。有些项目处于维护阶段，不打算增加新功能，甚至可能不打算修复小问题，但安全漏洞等严重问题仍然需要管理。这时候可以使用npmaudit命令列出项目依赖中存在安全漏洞的版本。当然处于活跃开发阶段的项目也需要注意安全漏洞，但是由于npminstall在引入新的依赖时会自动运行npmaudit，而npmoutdated会定时运行，所以手动运行的机会不多npm审计。npx之前说过，npminstall基本上只有在引入新的依赖的时候才会用到，没有提到全局安装。全局安装当然也需要使用npminstall。但是为了保证开发环境的一致性，npminstall--global还是要慎用。个人建议只在安装一些日常使用的工具时使用全局安装，将项目开发所需的工具作为开发依赖安装，然后使用npx调用。不推荐：npminstall--globalwebpackwebpack...推荐：npmi-Dwebpacknpxwebpack...其中i-D是install--save-dev的简写。对于一些一次性的临时任务，可以直接通过npx运行相应的工具，省去了手动安装的麻烦，也不会污染devDependencies。比如之前的项目是用webpack打包的，现在想临时试试用rollup打包的效果：npxrollup...npx很聪明，如果路径下找不到rollup，会自动安装。npx对于测试不同版本的兼容性非常有用。下面是一些例子。cowsay的某个需要用到的feature或者fix已经集成到github主线了，但是npmjs上还没有发布新版本。试试：npxgithub:piuccio/cowsay暂时测试一个内部维护的cowsay分支：npxgit+ssh://my.hosted.git:cowsay.git#semver:^1目前使用的是LTS版本的node(10)，我想试试看build脚本能不能在node12下运行：npx-pnode@12npmrunbuild从上面我们可以看出，当包名和命令名不同时（npm命令是node提供的），可以使用-p选项指定包名称。npmrun在package.json的scripts属性中添加命令（例如："foo":"echofoo"），通过npmrunfoo运行相应的命令。这是npm提供的一种非常方便的运行项目相关自动化任务的机制，有点类似于make。但是，直接运行make（不带任何参数）将运行默认任务，但直接运行npmrun（不带任何参数）将列出脚本中声明的所有命令。;leancloud-realtime中包含的npmrunLifecycle脚本：testnpmrunlint&&npmrunbuild&&npmrundocs&&npmruntest:node&&npmruntest:browseravailablevia`npmrun-script`:precommitpretty-quick--stagedcommitmsgcommitlint-e$GIT_PARAMSlinteslint--ignore-path.gitignoresrctestplugins&&tscrealtime.d.ts--strict...其他这里有一些tips我个人觉得不是特别实用，但是大家的需求和喜好是不同的，您可能会发现它们很有用。如果您有想要分享的技巧，请留言。npminit-y默认情况下，npminit会要求您回答一些问题。npminit-y可以跳过这些问题，直接开始开发。之所以不推荐，是因为如果你打算尽快开始开发一个应用，大多数情况下你会用到一个框架，而几乎所有的框架在npmjs上都至少有一个create-xxx-app包。所以基本上你没有机会输入npminit来回答这些问题。而如果你打算写一个组件或库，那么package.json中的元信息对于组件或库的使用者来说是非常重要的（即使是一个只供自己使用的组件或库，你也可能不记得在将来或库上下文中编写此组件），跳过这些问题不是一个好主意。当然，急躁是程序员的三大美德之一，你可能会想，等我开发完了再弥补吧。但是，一般来说，项目的开始是您对记录这些上下文最感兴趣（或者不太反感）的时候。如果在项目之初就迫不及待地去做这件事，开发完成后可能就更没有兴趣了。同样的，README也应该在项目开始之前写好。npmrepo打开项目的源代码存储库（大多数情况下是GitHub），它还有一个姊妹命令npmhome，用于打开项目的主页。不过个人觉得，相比这两个命令，一般来说，IDE或者编辑器的智能提示（peek类型、peek文档、peek定义等）效率更高。.npmignore文件可以列出你不想打包的文件，避免发布一些不相关的文件给npmjs。但是统一使用.gitignore可以满足大部分场景的需求。而且，当只有.gitignore存在时，npmpublish会尊重.gitignore的声明，而当.npmignore和.gitignore同时存在时，npmpublish会忽略.gitignore，而不是取两者的并集。换句话说，在.gitignore中忽略但在.npmignore中不忽略的文件被捆绑并发布。因此，使用.npmginore意味着小心维护两个列表，同时包含大部分重复内容。同时，一旦团队中任何人因不慎疏忽或不熟悉.npmignore和.gitignore之间的关系细节而出现错误，就有可能将敏感信息发布到npmjs中，导致安全事件的发生。各种npm命令的快捷方式版本，例如上面使用的npmi-D。这些人觉得没有必要刻意去背。对于经常输入的命令，可以运行npmhelp查看是否有短版。不检查也没关系，npmt和npmtest甚至npmruntest的区别绝不是开发效率的瓶颈。在许多情况下，这只是个人喜好问题。比如追求尽可能少打字的人会喜欢npmt，追求尽可能少东西的人会喜欢npmruntest（从来没遇到过因为误以为npmbuild是npmrunbuild问题），其他的可能更喜欢像npmtest这样的中间选项。npmxmas猜猜输入这个命令的结果是什么？你可以自己试试。提示：这个命令完全没用。;-)
