typescript 类型前端深爱的 TypeScript，是库开发者的“噩梦”李白被妻子刘氏嫌弃，写下一首爽诗，后2句被无数人奉为座右铭typescript abstract越早知道越好，

摘要：使用过 typescript 的前端开发者们，大多对 TypeScript 抱有好感，TypeScript 如今在前端领域也占据核心一隅。然而，在库开发者的眼里，TypeScript 似乎就很不“友好”了，本文作者亦是如此认为的。你在使用 TypeScript 时，是否遇到过这些问题呢？

原文链接：https://erock.prose.sh/typescript-terrible-for-library-developers

声明：本文为 CSDN 翻译，未经授权禁止转载。

作者 | Eric Bower译者 | 弯月出品 | CSDN（ID：CSDNnews）

以下为译文：

作为一名前端开发人员，我非常喜欢TypeScript。我感觉TypeScript大幅削减了手动编写自动化测试的需求，减轻了编写和维护自动化测试的负担，推动了开发人员生产力的提升。

但是，作为库开发人员，我非常讨厌TypeScript。我认为TypeScript不适合库开发，其中的原因有很多，但归根结底还是因为Typescript降低了开发人员的工作效率。实际上，我认为TypeScript将软件开发的复杂性从前端开发人员转嫁到了库开发人员，给每个希望成为TypeScript专家的人带来了巨大负担。

文档

TypeScript面向前端开发人员的文档和博客文章很丰富，但面向库开发人员的资源却很少。我所能找到的面向库开发人员的只有这一段有关类型操作的介绍（https://www.typescriptlang.org/docs/handbook/2/types-from-types.html）。

可能是因为他们认为库开发人员和前端开发人员并没有什么区别，恕我不能赞同。

为什么TypeScript官网没有提供任何有关库开发的指南？也没有任何推荐给库开发人员的工具指南？

事实上，TypeScript的应用开发与库开发之间存在一个巨大的鸿沟。Web应用很少需要条件类型、类型运算符和重载等结构。但库开发人员需要大量使用这些结构。这些构造是高度动态的，而且会在类型中加入逻辑。这导致我对TypeScript的调试大失所望。

调试

库开发人员如何调试高度动态且大量使用的条件类型以及负载？调试唯一可用的工具只有TypeScript的编译器和专业知识。你可以修改代码，然后看看类型最终的结果。在我看来，库开发人员只能凭直觉，除此之外没有任何更好的解决方案。

据我所知，库开发人员大量使用的唯一工具就是TypeScript演练场，他们可以在这个环境中将类型的逻辑分离出来，研究TypeScript将类型解析为另一种类型的原因。此外，你还可以在这个环境中轻松地修改TypeScript的版本和配置。

如果你知道任何TypeScript的调试工具，请不吝指教，因为我写这篇文章，不仅仅是为了发牢骚，更希望高人指点迷津。

复杂性

我使用了很长时间的redux，在我看来redux-toolkit是一个很了不起的库，你可以借助这个库查看真实的代码库是如何使用类型的。我必须说明，它们在类型方面的表现非常出色，但复杂度非常惊人。

下面是两个例子：

createAction #1：https://github.com/reduxjs/redux-toolkit/blob/4ab8c42cb20ae1e6f7b84a8ac0070eee54775b79/packages/toolkit/src/createAction.ts#L58

createAction #2：https://github.com/reduxjs/redux-toolkit/blob/4ab8c42cb20ae1e6f7b84a8ac0070eee54775b79/packages/toolkit/src/createAction.ts#L193

这个代码库中充斥着各种复杂类型。请注意类型的数量与实际的代码量。我大致统计了一下（忽略导入的代码），该文件中只有约10%的代码转译成了js代码（js代码：35行，代码总数：330行）。

风格指南中总是强调，不要使用嵌套的三元运算符。然而，在TypeScript中，你只能通过这种方式根据其他类型来缩小类型的范围。

测试

由于类型可以根据其他类型生成，而且这些类型高度动态，所以任何严肃的TypeScript项目都需要一类新型的测试：测试类型。在最新版本的TypeScript编译器上测试类型远远不够，你还需要针对以前的版本进行测试。

这类新型的测试还处于起步阶段，相关的工具有些已被弃用，而有些处于半维护状态。我曾使用过的库如下：

DefinitelyTyped-tools：https://github.com/microsoft/DefinitelyTyped-tools

tsd：https://github.com/SamVerschueren/tsd

dtslint：https://github.com/microsoft/dtslint

typings-checker（已被弃用)：https://github.com/danvk/typings-checker

该领域的人才大量流失，我的一些项目至今仍在使用已弃用的库，因为迁移代码会非常痛苦。

值得推荐的工具似乎只有两个：dtslint 和 tsd。为什么我们需要两个工具来完成大致相同的工作？这一点很令人迷惑。

维护

类型导致代码量急剧增加。当第一次尝试为项目贡献代码时，你必须了解应用程序的逻辑以及类型的逻辑。这会导致我们的心理压力增加，同时还会导致代码量急剧增加。举个例子，我在帮忙维护redux-saga，最近大多数的拉取请求和议题都是与类型相关的。

我花费在调整类型上的时间远远超过了编写库的代码。

虽然我很熟悉TypeScript，但我并不是专家。虽然我花费了数年时间编写TypeScript代码，但作为库开发人员，我仍然没有足够的知识来使用TypeScript，这让我倍感沮丧。精通语言似乎是一个先决条件。类型使得维护js库的难度加剧，为这些库贡献代码更是难上加难。

总结

我很喜欢TypeScript，而且我也同意TypeScript对前端开发有很大的帮助。TypeScript彻底改变了前端开发的格局，我们无法忽视它带来的巨大影响。

但作为库开发人员，我们需要：

更好的文档；

更好的工具；

减少花在讨tsc欢心的时间。

我只不过是为了弄清楚为什么TypeScript将一段代码解析为特定类型，也不至于要求我阅读TypeScript编译器的源代码吧？