依赖管理太麻烦？试试这个

项目地址

liuseen-l/kiwo: ⛄ a package.json dependent manager (github.com)

首先说说做这个工具的起因吧。可能是因为个人习惯不好，每次写项目的时候，特别是比较急的时候，不会特别在意安装的依赖是放在开发依赖还是生产依赖。以至于写好一些三方包后，到发布的时候需要手动调整这些依赖，调整的这个过程是比较繁琐的，为了解决这样一个问题，写了这样一个依赖管理工具，可以批量的调整依赖，比如将开发依赖移到生产依赖，或者生产依赖移到开发依赖。

如何使用

默认行为

因为当前工具只有移动依赖的功能，所以默认的指令行为是移动，执行npx kiwo，等价于执行 npx kiwo move. kiwo默认扫描的 package.json 是当前命令执行路径下的 package.json，也就是 process.cwd 路径下的package.json 。

这是执行 npx kiwo 后的效果，可以看到控制台是将 package.json 当中的开发依赖和生产依赖都展示出来了，这样有助于用户直观的了解项目当中的依赖情况，不需要再去 package.json 文件中查看。

下一步就是选择操作哪一个项目，因为默认情况是只扫描当前命令执行路径下的package.json，因此只有一个项目。选择好后进入到另一个界面，默认情况是移动生产依赖到开发依赖，勾选后工具就开始移动啦。

如果我们想移动开发依赖到生产依赖的话，只需要执行 npx kiwo 的时候，加上选项参数，即 npx kiwo -D 或者 npx kiwo -d 都行，以下是界面效果

多项目

目前很多项目选择monorepo架构，针对这类项目只需要在执行命令时添加选项参数即可，即 npx kiwo -r 或者 npx kiwo -R 都行，这样 kiwo 会从当前命令执行目录开始，往下递归查找 package.json，最后将找到的所有信息都进行展示。

js 复制代码

-root
    -foo
        package.json //假设package.json中name为pmm-playground
    package.sjon   //假设package.json中name为pmm

执行 npx kiwo -r 扫描结果如下图所示

这里可以看到，控制台将2个 package.json 信息都进行了展示，打上X是为了告诉用户此 package.json 中没有对应的依赖，之后的操作和之前所说的是一样了，选择项目 -> 选择移动的依赖，当然默认行为还是移动生产依赖，如果想移动开发依赖，可以执行 npx kiwo -r -d。

总结

当前工具适合三方包开发管理，因为业务方下载三方包时会涉及到三方包依赖的下载
一些业务项目可能不会在意这些包的管理，因为并不影响实际打包效果，但是如果规范要求得比较严苛的话，也可以使用

第一次掘金写文章，请大家多多指教，欢迎大家提出建议，pr 和 issues。