Vize
制作准备就绪
Vize仍处于实验阶段。
这并不是可以借口的免责声明。这是对当前阶段的描述。
目标是从实验项目转向生产准备的工具链。唯一诚实的道路是现实世界的认可和社区反馈。
玩具应用不够
小例子对发展很有帮助。
它们让我们可以隔离出一条规则、一条变换、一条源映射、一个编译器行为。
但制作版Vue项目并非小例子。它们包括：
- 不寻常的封装布局
- 旧Vue模式与新模式结合
- 路径别名
- 自动导入
- 宏量营养素
- 风格预处理器
- 深度嵌套组件
- 生成文件
- 框架公约
- 插件行为
- 平台特定问题
只传递玩具示例的工具链还不算生产准备。
这是一个带有不错演示的原型。
全面扫视很重要
这里最重要的是枯燥的工作。
Vize需要逐文件、逐个错误、通过诊断、逐快照地运行真实项目。
这意味着要检查：
- 构建输出
- 绒毛输出
- 类型检查输出
- 格式化稳定性
- 源地
- 路径解析
- 开发者-服务器行为
- 生产构建行为
- Windows与Unix的差异
这种详尽的工作并不光鲜亮丽。
但正是这些工作将“它以示例为例”转变为“它能经受真实存储保存”。
社区反馈是主要输入
社区会发现维护者未曾设想的案例。
这不是失败。这正是重点。
每一份真实的报告都很有价值：
- 无法编译的项目
- 使规则无法使用的假阳性
- 技术上正确但无助的诊断
- CI中的性能悬崖
- 缺少宏约定
- 仅限Windows的路径问题
- 指向一个标记的源地图
这些报告不是中断。它们就是数据集。
正确的做法是将它们转化为固定装置、测试、快照和基准测试。
制作准备是一种行为，而非标签
“生产准备”并不是因为README说明项目就变成了。
这是一种随时间变化的行为：
- 修复请求转变为回归测试
- 基准测试涵盖真实工作流程
- 发布说明 风险
- 破坏性变更是有意为之
- CI 表示支持的平台
- 诊断保持足够稳定以实现自动化
- 用户可以预测工具的具体操作
这对Vize尤其重要，因为它涉及多个层次。编译器不匹配、linter误报、类型检查不匹配或源映射错误，都可能以不同方式损害信任。
门槛高是因为表面积大。
为什么独立在这里有帮助
官方工具需要不同的谨慎。
它们立即承载生态系统的期望。他们不能过于激进地尝试，否则会影响大量用户。
Vize是独立的，这给了它快速移动的空间：
- 尝试架构变更
- 重写内部结构
- 添加严格诊断
- 测试备用编译器后端
- 去除弱抽象
- 追逐性能瓶颈
- 从社区报告中学习，但不承诺即时稳定
这种速度有用，但也伴随着责任。
项目必须明确其地位，并认真对待验证。
路线图是反馈形态的
实现生产准备的路径不仅仅是功能清单。
这是一个反馈循环：
- 在实际项目中使用 Vice。
- 将每一次故障记录为测试或夹具。
- 修复基础模型，而不仅仅是症状。
- 将行为与官方工具进行比较。
- 保持表现可见度。
- 反复练习，直到令人意外的案例变得无聊。
这就是工具链的形成方式。
不是假装自己完成了。
通过让真实的代码、真实用户和真实的约束来塑造工作，直到系统变得可信赖。