前端深爱的 TypeScript，是库开发者的“噩梦”
摘要：使用过 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编译器的源代码吧？
— 推荐阅读 —
