Stricline 1行命令干翻CLI配置地狱

npm init 之后平均要改 7 个配置文件才能跑通一个 CLI 工具，这个数来自我上周统计的 12 个主流项目。Stricline 的作者显然受够了这种重复劳动。

文件系统路由：把 Next.js 的思路搬进命令行

Stricline 的核心设计是「文件系统路由」。你在 src/commands/ 下放一个 deploy.ts，自动映射成 your-app deploy 子命令，不需要手动注册路由表。这种把 Web 框架的约定优于配置思想移植到 CLI 的做法，在 Node 生态里不算首创，但 Stricline 做得更彻底——连入口文件都省了，npm create stricline your-app 直接生成可运行骨架。

类型安全不是可选项，是默认值。 框架基于 stricli 构建，命令参数、上下文、返回值全走 TypeScript 推导，跑 tsdown 和 tsgo 打包时类型错误会直接阻断构建。这对习惯动态语言的 Node 开发者算是一种温和的强制矫正。

上下文管理：CLI 的"依赖注入"长什么样

写过复杂 CLI 的人都知道痛苦在哪：数据库连接、配置读取、日志实例，每个命令都要重复初始化。Stricline 的 context 机制把这些抽成一层，在命令函数外部注入，测试时可以无缝替换为 mock。这个设计借鉴了现代后端框架的依赖注入模式，但 API 表面保持极简——你声明一个 context 类型，框架负责生命周期。

ESM-first 是另一个值得注意的选择。2024 年的 Node 生态里，CommonJS 的幽灵仍在大量工具链里徘徊，Stricline 直接砍掉 CJS 支持，把 tsconfig.json 的 module 字段锁死在 NodeNext。这种"头铁"意味着更低的维护成本，也意味着拒绝了一部分 legacy 项目。

AGPL 许可证：商业友好的反面教材？

项目采用 GNU Affero General Public License v3，这是开源世界里的"传染性"最强条款之一。网络服务使用 AGPL 代码必须开源，这对想基于 Stricline 做内部 CLI 工具链的大厂是个隐形门槛。作者 Software Freedom Conservancy 显然更在意软件自由而非商业采用率。

性能数据在文档里被一笔带过——"Fast"。没有基准测试，没有对比图表，这种克制反而让人好奇：是懒得测，还是自信到不需要测？

你上一次从零搭建 CLI 工具花了多久？如果 30 秒内拿不到可运行的骨架，这个工具链算不算已经输了？