全文：采用过 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编译器的源代码吧？
