TypeScript 干预：使用 Byzantium 打破运行时检查成瘾

听着，我们需要谈谈你的类型检查瘾。是的，您——在您的身份验证中间件中进行了 47 个instanceof 检查。编写的测试用例多于实际代码的开发人员。将 TypeScript 视为只是花哨的 JSDoc 注释的人。

干预

让我给你画一幅图画：现在是中午，你正在喝第四杯咖啡，并且正在调试一个生产问题。日志显示用户以某种方式通过了十五层运行时验证。你的单元测试比 Twitter 的活跃用户还要多，但不知何故，不知何故，有人设法在应该是字符串的地方发送了一个数字。

“但那是不可能的！”你哭了，滚动浏览测试覆盖率报告，显示原始的 100%。 “我检查过这个！”

你有吗？你真的吗？或者您是否只是将同一张支票写了三遍：

1. 一旦进入 TypeScript 界面
2. 再次在您的验证中间件中
3. 再次在单元测试中

停止测试 TypeScript 已经知道的内容

这是一个革命性的想法：如果我们......信任编译器会怎样？我知道，疯狂的概念。但请听我说完。

interface ValidRabbit {
    username: string;
    password: string;
}
interface InvalidRabbit {
    username: number;
    password: string;
}


type ValidateRabbit<Rabbit> = Assert<
    //assert that Rabbit is of type {username, password}
    Is.Type<
        User,
        {
            username: string;
            password: string;
        }
    >,
    //custom compile time exceptions
    "Trix are for kids. Provide a username and password.",
    User
>;

// Ha! Silly Rabbit...
function checkRabbit<T>(rabbit: ValidateRabbit<T>) {
    // .... protect your trix
}

declare const rabbit1: ValidRabbit;
declare const rabbit2: InvalidRabbit;

checkRabbit(rabbit1);
checkRabbit(rabbit2);
/**        ~~~~~~~~~
 *           └───── Type Exception! "...Provide a username and password"
 */

“但是生产呢？”

我现在可以听到您的声音：“但是如果有人向我的 API 发送无效的 JSON 怎么办？”

首先，谁伤害了你？其次，是的，验证您的 API 边界。但是，一旦该数据进入您的打字稿域，就该放手了。让编译器成为你的保镖。

以下是拜占庭为您的信任问题聚会带来的内容：

// Define your trust boundaries
type APIRequest<Request> = Assert<
    And<
    Is.On<Request, "body">,
    Or<Is.In<Request["method"], "POST">, Is.In<Request["method"], "PUT">>
>;,
    "Someone's being naughty with our API"
>;

// Now everything inside is type-safe
function handleRequest<R>(req: APIRequest<R>) {
    // If it compiles, it's valid
    // If it's valid, it compiles
    // This is the way
}

DevOps 团队会爱你（一次）

想象一下：您的 CI/CD 管道在几分钟内完成，而不是几小时。您的生产日志中不会充满类型错误。您的 AWS 账单看起来不像电话号码。

怎么样？因为拜占庭将类型检查移至编译时。没有了：

• 运行数千个仅检查类型的单元测试
• 消耗 CPU 周期一遍又一遍地检查相同的类型
• 凌晨 3 点醒来，因为有人将 undefined 传递给一个明确表示需要字符串的函数

// Before: Your CPU crying for help
function validateUserMiddleware(req, res, next) {
    try {
        validateId(req.params.id)        // CPU cycle
        validateBody(req.body)           // CPU cycle
        validatePermissions(req.user)    // CPU cycle
        validateToken(req.headers.auth)  // CPU cycle
        // Your CPU is now considering a career change
        next()
    } catch (e) {
        res.status(400).json({ error: e.message })
    }
}

// After: Your CPU sending you a thank you note
type ValidRequest = Assert<
    And<
        Is.On<Request, 'params.id'>,
        Is.On<Request, 'body'>,
        Is.On<Request, 'user'>,
        Is.On<Request, 'headers.auth'>
    >,
    "Invalid request shape"
>;

function handleRequest(req: ValidRequest) {
    // Just business logic, no trust issues
}

“但我喜欢写测试！”

伟大的！为真正需要测试的东西编写测试：

• 业务逻辑
• 整合点
• 用户工作流程
• 复杂算法

你知道什么不需要测试吗？字符串是否实际上是字符串。让 TypeScript 来处理这场生存危机。

真实的谈话：好处

1. 更快的发展

   • 不再用三种不同的方式编写相同的验证
   • 在编译时捕获错误，而不是在凌晨 3 点
   • 花时间在功能上，而不是验证样板

2. 更好的性能

   • 类型检查的零运行时开销
   • 更小的包大小（无验证库）
   • 快乐的CPU，快乐的生活

3. 提高安全性

   • 类型级保证无法被绕过
   • 不再有“哎呀，忘了验证”
   • 默认完全覆盖

4. DevOps 梦想

   • 更快的 CI/CD 管道
   • 降低基础设施成本
   • 生产事故减少
   • SRE 团队更快乐（结果可能会有所不同）

入门

interface ValidRabbit {
    username: string;
    password: string;
}
interface InvalidRabbit {
    username: number;
    password: string;
}


type ValidateRabbit<Rabbit> = Assert<
    //assert that Rabbit is of type {username, password}
    Is.Type<
        User,
        {
            username: string;
            password: string;
        }
    >,
    //custom compile time exceptions
    "Trix are for kids. Provide a username and password.",
    User
>;

// Ha! Silly Rabbit...
function checkRabbit<T>(rabbit: ValidateRabbit<T>) {
    // .... protect your trix
}

declare const rabbit1: ValidRabbit;
declare const rabbit2: InvalidRabbit;

checkRabbit(rabbit1);
checkRabbit(rabbit2);
/**        ~~~~~~~~~
 *           └───── Type Exception! "...Provide a username and password"
 */

选择是你的

您可以继续生活在恐惧中，为所有内容编写运行时检查，将 TypeScript 视为 JavaScript 的可选类型。

或者您可以在 2024 年加入我们，我们信任我们的编译器并让它完成其工作。

记住：每次你编写运行时类型检查时，TypeScript 编译器都会在某个地方哭泣。

结论

Byzantium 不仅仅是另一个库——它是对类型信任问题的干预。是时候放弃运行时检查并拥抱编译时保证的力量了。

您的 CPU 会感谢您的。您的 DevOps 团队会感谢您。您的用户会感谢您（因为没有发现与类型相关的错误）。

最重要的是，你会在凌晨 3 点感谢自己，当时你睡得很熟，而不是在生产中调试类型错误。

---

P.S.如果您仍然不相信，请尝试计算代码库中有多少个运行时类型检查。然后乘以你的小时费率。这就是你花费了多少时间不信任 TypeScript。

P.P.S.在撰写这篇博文的过程中，没有人受到伤害。尽管一些运行时检查已永久停用。

*P.P.P.S。如果您想做出贡献，请访问我的 Github 并克隆该存储库。一切都还是新鲜的，所以有很多贡献的机会。

JSR.io 上提供的文档和包

以上是TypeScript 干预：使用 Byzantium 打破运行时检查成瘾的详细内容。更多信息请关注PHP中文网其他相关文章！