为什么TypeScript是每个新的PayPal Web应用程序的核心？

我们最近发布了Eric Elliot批评TypeScript的材料。 今天，请您注意肯特·多德斯（Kent Dodds）文章的翻译。 在这里，他谈到了为什么PayPal从Flow切换到TypeScript。

背景知识

我在PayPal工作，并参与了paypal-scripts库，该库是一个工具箱，让人想起create-react-app或angular-cli或ember-cli的react-scripts 。 我已经写过这个。 该库的基础是将PayPal应用程序和已发布模块中使用的所有工具进行组合的想法。 创建paypal-scripts是从package.json和所有配置文件中获取所有开发依赖项devDependencies ，并将所有这些依赖项devDependencies为devDependencies部分中的单个条目。 并且，由于所有配置都在一个软件包中，因此在创建过程中它们遵循关于什么是好的特定观点，为了使这些工具保持最新状态，仅更新一个依赖项就足够了（实际上是paypal-scripts ） ，这些更新本身通常不包含可能破坏依赖于此代码的操作的某些内容。 结果，足以保持一种依赖性并冷静地参与应用程序开发。

在过去的一年中，贝宝（PayPal）程序员习惯于使用贝paypal-scripts 。 在这里，要创建一个新应用程序，只需单击Web界面中的几个按钮，即可创建公司GitHub存储库，配置项目部署工具，持续集成系统等。 自动生成的存储库基于sample-app存储库。

就在上周，它包括我的添加内容，旨在在其中使用paypal-script 。 这意味着，贝宝中每个新应用程序的核心都是基于现代技术和工具构建的框架，该应用程序的开发人员无需担心其更新。 其中，此类应用程序将使用TypeScript进行静态类型化，并使用Jest工具进行测试。

老实说，这已经成为我职业生涯的万能大作。 我不认为有一天我能够在PayPal中达到类似的水平。 这个项目产生了巨大的影响，我感谢贝宝（PayPal）进行如此大规模的工作的机会。

因此，我向您介绍了整个过程，现在让我们谈谈TypeScript。

在12月中旬，我致力于将paypal-scripts集成到sample-app 。 我还致力于pp-react （并继续进行工作），该pp-react是一个适合重用的组件库（按钮，窗口，样式）。 由于paypal-scripts支持可以发布的模块，因此我使用react-scripts来构建pp-react 。 一个月前， paypal-scripts库包含对Flow的支持。 借助Babel，很容易将此类支持添加到该库中。

在12月12日，当我在Flow支持方面研究pp-react和新版本的sample-app时，我感到我已经对Flow感到非常厌倦（我将在下面进行详细讨论）并做出了意外的决定。 我给同事写了一封信，询问他如何看待我将如何使TypeScript在sample-app 。 他回答：“是的。” 然后，我在#paypal-scripts Slack频道上进行了一项调查，结果表明所有参与者都支持我的想法。 对我来说，所有这些足以开始工作。 大约一周后，我将paypal-scripts从Flow支持完全转换为TypeScript支持。 大部分时间都花在了教所有识别.ts和.tsx文件.ts的工具上，以及让paypal-scripts程序包进行自我测试，这是一项相当艰巨的任务。 然后，我花了几天时间在sample-app存储库中进行PR，目的是使用新的经过改进的paypal-scripts库，以及从.js文件切换到.ts和。 tsx文件。 然后有假期，然后我的公关被批准了。 结果，现在在每个新项目中，PayPal都使用静态TypeScript类型。

当然，在某人创建新项目后，他可以随心所欲。 说，您可以删除所有样板代码并将其写在Elm或其他任何东西上。 这是完全正常的。 但是，由于所谓的“ 默认效果 ”，大多数项目的作者坚持使用用于创建它们的那些技术。

为什么我这么长时间使用TypeScript？

本节标题中提出的问题通常是TypeScript爱好者提出的。 事实是我很熟悉TypeScript，但是与这种语言的关系已有一段时间没有发展。 因此，我记得大约在2013年，一位同事建议我将大约50万行代码转换为TypeScript。 然后我拒绝了这个提议，但是我并不特别后悔，因为在那个年代TS是一种相当年轻的语言。 而且甚至有一次我采访了TypeScript的创建者Anders Halesberg 。

这就是为什么我一直都远离TypeScript的原因。

▍原因编号1。 担心破坏基于Babel和ESLint的工作环境

对我来说，很长一段时间以来，在TypeScript之前使用Flow的主要优点是可以将Flow与我习惯的工具更好地结合在一起。 特别是，我多年来一直在愉快地使用Babel和ESLint，我喜欢为它们两个编写自己的插件（顺便说一句，您也可以学到这一点）。 我喜欢Babel和ESLint周围有大量社区的事实。 结果，我断然不想拒绝他们。 实际上，这种情况一直持续到最近发生的事件为止，因为如果我打算把TypeScript放在脑后，那么我将不得不同时离开这两个。 当然，在TypeScript世界中有TSLint这样的东西，但是ESLint社区更大。

在Flow中，我特别喜欢这样一个事实：要将其包含在您的工作流中，只需执行几个简单的步骤：

1. 必须将支持相应语法的预设连接到Babel。
2. 您需要将// @flow构造添加到每个文件的开头，即要在其中进行组织的类型检查（有一个ESLint 插件可以让您检查）。
3. 将脚本添加到项目中，该脚本允许您运行Flow来检查代码库中的类型。

我非常喜欢以下事实：类型检查（使用Flow）和构建项目（使用Babel，Webpack或Rollup）是分开的。 我不想将我的生活与TypeScript联系起来，尤其是因为它的编译器在任何情况下都不会理解我自己开发的Babel插件。 而且-由于我拥有Flow的事实-一个相当不错的工具。

现在一切都照常进行。 多亏了Babel 7（特别是我们在谈论@ babel / preset-typescript ），您可以保存熟悉的工具，并且可以使用TypeScript的大多数功能。 主要问题是使工具接受带有扩展名的文件。 ts和.tsx ，但幸运的是，此问题已解决。

▍原因编号2。 贡献者将必须学习TypeScript才能为项目做出贡献。

我主要是在谈论开源，但是那些想为项目做贡献的人学习TypeScript的需求也适用于我在工作中所做的事情。 同时，我始终认为应该键入工作项目，这是通过Flow来实现的。 我试图在开源项目中不要使用Flow，因为那些决定加入Flow的人必须学习Flow。 我本人一直在谈论这个问题，但是在潜意识里，我总是引用一个反驳的观点，即事实上，打字本质上只是另一种测试形式，但是想要为开源做贡献的人必须弄清楚这一点。与测试。

坦率地说，仅因为潜在的贡献者可能没有所有权而拒绝在开源中使用某种技术，在我看来，这是不使用该技术的不好借口。 而且，随着越来越多的程序员掌握TypeScript，我认为也许过一会儿我将对TS和我的开源项目进行写作。

▍原因编号3。 强大的流类型推断系统

我读了这篇文章，我真的很喜欢它。 尤其是它的最后一行，在使用时，根据该行添加了Flow类型，以使错误消息更加令人愉悦，而不是为了识别它们。

就是这样 如今，Flow具有比TypeScript更强大的类型推断系统，这鼓舞了我。

▍原因编号4。 流，像React一样，最初来自Facebook

如果我说我不屈服于普遍的误解，即我相信如果一家公司做了一件伟大的事情，那么它所做的所有其他事情都会自动处于相同的高水平，我会冒犯真理。 根本不能保证。 我没有其他要在这里添加的内容。

▍原因5。 TypeScript狂热分子

我想每个人都知道，如果某人对某种技术非常着迷，那么他会不停地告诉周围的人。 有人在这里使用vim吗？ TypeScript依附者也不例外。

顺便说一下，TypeScript社区充满了很多人。 善良，乐于帮助，热情，友好。 但是我不得不遇到这样的TS爱好者，他们会称其为傻瓜，只是因为他不使用TypeScript，不理解它或使用其他东西。 他们表现出缺乏理解对话者的能力，并且他们的位置使人无聊。 这不是我想加入的社区。 我的意思是，某人选择的技术引起的热情很棒，但是如果这种技术的发展程度如此之高，以致于它的粉丝开始压迫那些选择其他东西的人，那已经很可悲了 。

我对此仍然有些担忧。 但我希望我们在一起可以使TypeScript社区更加积极。

现在，我已经讨论了为什么我不着急改用TypeScript的原因，我将讨论Flow中不适合我的内容。

流程问题

正如我所说，在某些时候，我对Flow非常厌倦。 这是我分享了使用Flow时遇到的主要问题之一的推文之一。 它包含以下事实：为了使Flow能够正常工作，在启动失败后，通常有必要先停止它，然后再重新启动它。 这是我的另一条关于Flow故障的推文 。

最终，由于经常出现的可靠性问题，我被Flow抛弃了。 可以这么说，用于编辑器的插件取得了不同程度的成功（我必须承认我没有与Nuclide一起工作，也许，如果我尝试使用Nuclide，我的生活会有所不同，但是我尝试与Flow在Atom和VSCode中一起工作），我不断面对一些奇怪的事情。 这很烦人，因为它破坏了我对我使用的类型控制系统的信心。

当我在11月看到此推文时，他表达了我已经在想的事情。 关于从Flow切换到TypeScript的简短故事与我对这种情况的看法不谋而合。 老实说，我不能停止思考如何正确使用TypeScript。 结果，我做到了，对此我感到非常高兴。

问与答

▍您为什么不使用TSLint？

实际上，我在paypal-script实现了TSLint支持。 这是我获得的第一批剧本之一。 我将根据项目是否具有tsconfig.json文件来决定使用TSLint还是ESLint。 但是后来我想起来，我们有一些自己设计的ESLint插件（例如，检查国际化），我不想浪费时间以TSLint插件的形式进行重写。 另外，TSLint命令行界面不如ESLint强大，并且不适用于使用paypal-scripts 。 也许过一会儿我将仔细研究TSLint。

是的，我想指出，ESLint社区仍然比TSLint社区大得多。 另外，我逐渐意识到，好的类型控制系统会使linting插件失效。 在此期间，我正在使用TypeScript ESLint，得到的效果还不错。 这是我关于这个主题的视频。

顺便说一下，我觉得TypeScript团队倾向于ESLint，所以我想我做出了正确的选择。

▍您为什么不选择理性？

在此推文的对应中，我回答了尝试使用TypeScript的提议，并说最好从Flow切换到ReasonML。 实际上，在切换到TypeScript之前，我经常谈论切换到Reason 。 做出此类声明的主要原因之一是我希望保留已经讨论过的常用工具。 但是，由于我不必放弃任何事情，因此TypeScript对我更具吸引力。 我仍然很喜欢Reason，但是对于许多PayPal员工来说，改用Reason意味着巨大的改变。 而且，尽管我认为他们可以解决这个问题，但我相信他们使用TypeScript会比尝试学习一种新语言更舒服。

如果我选择了Reason，那么我的PR可能永远不会进入sample-app存储库。 鼓励同事使用实质上是一件事，即所谓的“类型化JavaScript”（特别是如果他们不需要对某些配置的支持），并且如果您尝试鼓励同事使用，则将发生完全不同的对话。完全不同的语言和完全不同的生态系统（这种语言与JS和npm交互的程度无关紧要）。

总结

现在，我要感谢所有影响我对TypeScript愿景的Twitter用户。 正如我所说， paypal-scripts库进入Pay​​Pal的sample-app仓库的事实可能是我职业的主要成就。 而且我相信，现在公司默认情况下所有公司所有新应用程序的模板都配备了TypeScript支持，这对所有PayPal员工来说都是一个巨大的优势。 我很高兴选择TypeScript。

亲爱的读者们！ 您认为使用Flow的人应该朝TypeScript的方向看吗？