migrate-to-shoehorn

migrate-to-shoehorn 技能概览

migrate-to-shoehorn 技能能做什么

migrate-to-shoehorn 技能可以帮助你把测试代码里脆弱的 as 类型断言替换为 @total-typescript/shoehorn，这样你就能更轻松地构建部分测试数据，而不用和 TypeScript 反复拉扯。它特别适合处理过大的 fixture、只关心少数嵌套字段的场景，或者清理测试中大量的 as unknown as Type 模式。

适合谁用

如果你在 TypeScript 测试套件里工作，希望用更少的样板代码构造更安全的 fixture，那么就该用这个 migrate-to-shoehorn 技能。它尤其适合正在更新旧测试、编写新的集成风格测试，或者在一个仍然大量依赖断言式 mock 的代码库里做统一规范的工程师。

它为什么有用

它的核心价值不只是做语法替换；更重要的是，它能降低测试搭建的摩擦，同时把类型意图保留下来。这个技能会引导你在不完整对象上使用 fromPartial()，在测试刻意打破类型形状时使用 fromAny()，把取舍显式化，而不是藏在断言里。

如何使用 migrate-to-shoehorn 技能

安装 migrate-to-shoehorn 技能

使用下面的命令安装：

npx skills add mattpocock/skills --skill migrate-to-shoehorn

安装后，先阅读 SKILL.md，再检查环境里存在的关联仓库文件。对于这个 repo 来说，技能内容集中在一个文件里，所以实际指导会紧贴实现示例展开。

把模糊目标变成高质量提示词

最好的 migrate-to-shoehorn 用法，始于具体的测试片段，而不是一句笼统请求。好的输入像是：“把这个测试从 as Request 改成 fromPartial()，并保留现有断言行为”，或者“把这些 as unknown as fixture 重写成使用 fromAny()，因为测试本来就故意传了无效数据”。

这个技能需要你提供什么

请提供对象结构、测试框架上下文，以及你想移除的确切断言模式。如果 fixture 是深层嵌套的，也要指出真正重要的属性，因为这个技能最擅长保留必要字段、删掉其余伪造结构。

实用工作流与 repo 阅读路径

先看 SKILL.md，确认迁移模式，再去找测试里当前使用 as Type 或 as unknown as Type 的地方。在应用 migrate-to-shoehorn 指南时，先判断测试需要的是“有效的部分数据”还是“故意无效的数据”；这个选择决定了该用 fromPartial() 还是 fromAny() 来替换。

migrate-to-shoehorn 技能 FAQ

migrate-to-shoehorn 只适用于测试吗？

是的。这个技能明确是给测试代码用的，不是给生产代码用的。如果你需要运行时校验或适用于生产环境的强制转换，migrate-to-shoehorn 就不是合适工具。

什么时候该用 fromPartial()，什么时候该用 fromAny()？

当对象是不完整的，但结构上仍然和目标类型对得上时，用 fromPartial()。当测试刻意提供无效或不可能出现的值，需要绕过该场景下的类型检查时，用 fromAny()。

migrate-to-shoehorn 技能比通用提示词更好吗？

通常是的，因为它提供的是一个聚焦的迁移模式，而不是泛泛建议。通用提示词可能只会说“避免断言”，但 migrate-to-shoehorn 技能会直接告诉你该用哪种替换方式，以及如何处理大型 fixture 对象，从而减少重写时的猜测。

它适合新手吗？

适合，只要你已经了解基本的 TypeScript 测试。主要学习成本在于判断你的 fixture 属于“部分但有效”还是“故意不安全”，因为这会决定该用哪个 helper。

如何改进 migrate-to-shoehorn 技能

把真实的测试意图告诉技能

最强的 migrate-to-shoehorn 输入，不只是对象字面量，还包括测试到底在验证什么行为。比如“这个测试只关心 body.id 和 headers.authorization”，会比“转换这个 fixture”产出更好的结果，因为技能能把对象收缩到最有意义的最小形状。

避免两个常见失败模式

第一个失败模式是保留了太多 fixture 噪音，这会直接抵消使用 migrate-to-shoehorn 的意义。第二个是处处都用 fromAny()，这样会削弱类型信号；应优先选择最贴合测试意图、范围最窄的 helper。

在第一次转换后继续迭代

完成第一轮 migrate-to-shoehorn 转换后，检查测试是否仍然清楚表达了契约。如果输出里还有不必要的属性，就删掉它们；如果测试确实需要一个不安全值，确认 fromAny() 的选择是有意为之，并且场景本身已经体现出来。

按仓库特定约束调整提示词

如果你的代码库有测试约定，务必提前说明：比如 Jest 还是 Vitest、factory helper、共享 request 对象，或者针对 import 的 lint 规则。这样的上下文能帮助 migrate-to-shoehorn 技能产出更贴合你仓库的改动，而不只是把语法翻过去。