文章和视频都可以,最好是基于 cac | commander 的
最好不只是介绍 cac 的 api,而是包括:
- 怎么调试方便
- 怎么打包产物
- 怎么支持 ts
- 开发 cli 的经验
文章和视频都可以,最好是基于 cac | commander 的
最好不只是介绍 cac 的 api,而是包括:
10 回答11.1k 阅读
6 回答3k 阅读
5 回答4.8k 阅读✓ 已解决
4 回答3.1k 阅读✓ 已解决
2 回答2.6k 阅读✓ 已解决
3 回答5.1k 阅读✓ 已解决
3 回答1.8k 阅读✓ 已解决
命令行程序一般分为两种类型,
先说只带选项和参数的,大概是分为 switch 和 option 两种。
键值对根据不同的定义,又分好多种形式,不过常用的也就三种:
--key value
--key=value
--key:value
其中后两种多用于 Windows 下,
=
和:
用来代替空格。说到这里又得提到参数的表示形式,也跟系统有点关系,Linux 下多种
-c
和--word
的形式,前者是简写,后者是全称(用单词全称比较容易理解)。Windows 下从 DOS 继承的是
/xx
,不分简称全称,使用/
作为参数识别符,后来逐渐开始兼容-
和--
。有些时候这两个符号都是代替/
的,也有时候按 Linux 的规范来,最神奇的是有些命令行程序也会把-
和--
识别为不同的参数,比如-c
和--c
不同……当然这种奇葩不推荐。扯远了。现在既然是用库来定义和解析参数,那基本上都是 Linux 那种规范来的。解析器解析了这些参数之后,一般会把它们封装成一个 Option 对象(也就是说的 Option 模式),比如
接下来就是根据这个参数对象来实现你自己的命令行业务行为。具体业务具体分析,也没什么特别好说的。
如果是带子命令形式,比如
npm run serve
,这里run
其实是一个子命令。常见的还有 git 和 dotnet 这些都是以子命令形式实现的,dotnet 甚至还通过插件/组件来实现子命令的扩展。由于存在子命令,所以会行解析命令行的第一个参数来判断是什么命令,然后再解析后面的参数送给这个命令去处理它自己的业务。这种根据不同命令来进行处理,但又基本上是一致的调用逻辑(解析参数传给命令处理),可以参考 23 种设计模式中的命令模式 (Command Pattern),或者用策略模式也可解决这类问题。总之,组件就是帮你处理命令行参数的,但拿到参数之后怎么做,还是看你自己想实现的业务来