项目地址
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。