作为前端开发者，你有没有被node_modules困扰过？反正我有。..由于npm特殊的包管理机制，往往一个小项目会承载一个很大的node_modules。相信大家都看过下图，这是对前端依赖的最大讽刺。有时，我们可能会不经意地引入一个意料之外的依赖包，或者不小心升级了一个依赖的breakchage，或者在一个项目中安装了多个相互冲突的依赖版本。但是每次遇到这种问题，都需要花费大量的时间来排查问题。比如我们想查询项目中某个依赖的安装情况，可以使用npmls命令，但是这个命令速度太慢，而且打印出来的信息比较混乱。还是直接去开锁查看版本？您可能需要花费更多时间，并且可能无法找到所有内容。qnm最近在Github发现了一个宝藏CLI工具：qnm，可以帮助我们快速梳理前端依赖信息，同时支持npm和yarn。我们可以全局安装，或者使用npx调用：npmi--globalqnmanalysisdependencyusage:qnm[module]，我们尝试查看所有安装的lodash：这说明，lodash在我们的项目中已经安装了15次。我们项目直接依赖的版本是4.17.11，是3年前发布的（已经很落后了）。其他间接依赖都是1周前发布的4.17.21版本。对比一下实际的node_modules目录，发现可以一一匹配：对比一下npmlslodash的结果，对比起来真的又慢又乱：也可以对packages进行模糊搜索（命令直接输入qnmline):另外还有一些参数选项：--no-remote:禁止从npm获取远程数据，可以加快命令速度；-o,--open：使用默认编辑器package.json文件打开模块；-d,--debug：查看完整的错误信息，主要用于调试；--disable-colors：禁用大多数颜色和样式，例如版本颜色。分析空间占用可以使用qnmdoctor分析node_modules目录下占用空间最多的内容。这个分析让我很惊讶。一些老项目node_modules已经占用好几个G空间了。.调用qnmdoctor--sortduplicates查看重复依赖占用的空间：分析所有模块调用qnmlist命令分析node_modules目录下的所有模块（相当于直接调用npmls，但是比它的速度和可读性要好很多up).模糊匹配qnmmatch命令类似于grep命令，可以匹配任何包含特定字符串的模块。比如我们想看看自己安装了哪些babel插件：怎么样，用这个命令行工具管理node_modules是不是感觉更简单？赶紧收藏吧（https://github.com/ranyitz/qnm）！
