TypeScript的4个未来挑战

键入的Javascript为Web开发带来了新的水平。 更好的自动完成功能，更有信心地进行重构， 减少了错误 -拥有类型检查器很棒。 有几种类型的语言可以转换为javascript。 有TypeScript，Flow，Elm，ClojureScript，Reason，Kotlin等。其中最受欢迎的是TypeScript。

虽然我认为TypeScript很棒-但这不是所有的阳光和彩虹。 这是TypeScript未来面临的四个最大挑战。

配置TypeScript可能很麻烦

这是JavaScript世界中的一个普遍问题。 对于新手来说，构建系统并不容易。 无法配置Webpack简直是在开玩笑，还有通天塔—现在还有TypeScript，它有自己的设置难题。

我认为这种迷宫般的复杂性是采用无配置（如angular cli，Create React App和ParcelJS）这样的无配置构建工具的原因之一。

虽然TypeScript具有一些合理合理的默认值，但是在tsconfig.json文件中仍然存在（计数为） 54个编译器标志，这些标志是在设置项目时创建的。 现在，它们中的大多数具有合理合理的默认值，并且添加了许多默认值以防止破坏更改-但是在帮助调试了我的有问题的tsconfig文件后，我可以告诉您肯定有人错了。

全部54个！

现在，使用每个标志作为注释生成tsconfig.json绝对是有帮助的，因此可以查看要打开的旋钮，但是弄清楚要使用的JavaScript目标，要使用的模块系统，要使用的模块仍然tsconfig.json方便。包含的库等

使TypeScript适应JS生态系统

现在，尽管TypeScript带有一些配置选项，但是当您要将其与其他构建工具结合使用时，复杂性实际上开始激增。

假设我们要在Webpack构建管道中使用TypeScript。 我们使用加载程序来做到这一点，但是我们应该使用ats还是ts-loader吗？ 还是我们应该只运行"tsc --watch" ，然后使用编译后的输出并将其输入到webpack中？

每个webpack加载器都有其自己的一组选项。 ats具有18个设置， ts-loader具有19个不同选项。

但是也许我们根本不应该使用TypeScript加载器？ Babel 7具有TypeScript支持-仍处于beta中，但是许多大型项目已经在使用它，并且看起来很稳定。 但是，babel TypeScript支持在您很少使用的某些事情上受到限制（常量枚举和名称空间是其中的两个），那么您是否愿意为了进一步简化而进行权衡？

@iamdevloper知道感觉如何

然后，您当然当然也需要使其与您的测试框架一起使用-Jest具有ts-jest作为TypeScript的预处理器，但是它也有局限性和一些10多种配置选项。 而且，您最好确保它的配置方式与上述Typescript-loader相同，否则您将遇到难以调试的不一致情况。

所有这些都是完全可行的，并且现在不需要很长的时间就可以建立打字稿项目，但是我已经花了很多时间，而且我被很多次的辛苦弄清楚是怎么回事。 绝对很难上手。

类型系统错误消息是含糊的

虽然TypeScript的目标是按原样键入JavaScript，但是考虑到JavaScript的动态程度，这可能很难。 像这样的任务需要复杂的类型系统，因为它必须键入的现实生活场景非常复杂。

好消息是TypeScript类型系统功能非常强大，您可以用它做一些令人惊奇的事情。

糟糕的是，当它不起作用时，绝对不可能弄清楚到底是怎么回事。 考虑这个谈话我在twitter上前段时间：

@michlbrmly对条件类型做了一些很酷的工作：

具体细节并不是很重要，但是使用一些巧妙的类型系统魔术，它定义了一个对象，该对象同时包含可翻译键和不可翻译键进行本地化。

这里首先要注意的是，尽管这些类型非常聪明-它们也足够聪明，以至于即使有描述它们的注释，我也很难弄清发生了什么。

现在，第二个问题是-如果库使用了这些类型，而您指定了错误的类型。 这是您将收到的错误消息：

所以..这到底是怎么了？ 绝对不可能从错误消息中分辨出来。 这不是一个孤立的案例，我之前曾使用react-redux尝试过此类错误消息。

对我来说，真正的恐惧是，随着类型系统复杂性的增加，在某些时候它会变得如此复杂以至于毫无用处。 如果您无法弄清楚类型告诉您的内容，那么它们所提供的帮助就不止于它们，它们只是无法理解的错误消息的聚集枪。 TypeScript 3.0 在路线图上有更好的错误消息 ，因此希望这是团队关注的事情。

生态系统碎片化

React Native 0.56在其更新日志中包含了此代码段

“我们正在从PropTypes和运行时检查中迁移，而是依靠Flow。 您会在此版本中注意到与Flow相关的许多改进。”

有了以上转译为js语言的几种变体，我认为存在真正的生态系统碎片化风险。

“该库仅具有TypeScript类型。 好？ 仅当您使用Flow时才能使用此类型。 但是我正在使用ReasonML，该怎么办？”

我认为目前有很多重复的工作，需要在JavaScript的不同方言之间键入相同的库以互操作。 对此没有简单的解决方案，因为在Kotlin中找到的类型系统不能立即使用TypeScript中的类型，因为Kotlin中的类型系统不够动态，无法理解诸如映射类型之类的东西。

我认为考虑到我们是否需要某种标准类型格式（就像我们使用源映射一样）对生态系统有益。 它可能不会像TypeScript类型那样复杂，但这也可以-大多数库无论如何都没有那么复杂的类型，

我认为，如果我们最终进入不同的围墙式花园，那将是一场悲剧。

边界类型检查

其中的一个既定目标打字稿的非目标是这样 ：

“ 在程序中添加或依赖于运行时类型信息，或者根据类型系统的结果发出不同的代码。 相反，鼓励 不需要运行时元数据的 编程 模式。”

我认为这有优点也有缺点。 在大多数情况下-很好。 在某些地方您想在应用程序内使用类型信息，依赖注入可能是最大的地方。 但是，这可以通过使用实验的emitDecoratorMetaData标志在Angular和InversifyJS之类的问题中解决。

但是，真正有用的最大方法是在应用程序边界进行类型检查。 在大多数类型的语言中，您可以表达自己正在接受具有X形状的对象的请求。

在TypeScript中，您当然可以做同样的事情-但由于类型信息在运行时不执行任何操作，因此无法确保您所期望的类型实际上是您所获得的类型。

如果您关心对象的结构，则需要在运行时使用类验证器或io-ts之 类的对象来指定它，但这需要您以某种方式指定类型，即意见比TypeScript界面​​要优雅得多。

现在，TypeScript实际上正在使用未知的新top类型进行边界检查方面的工作-这基本上是我们一无所知的类型。 您可以接受类型unknown的边界对象-然后您必须在运行时检查其实际类型。

我仍然认为诸如运行时检查，ala flow-runtime之类的内容对于TypeScript是有意义的。 诸如"validate"关键字或“validateType()”函数之类的已编译为函数的东西，可确保对象实际上是所声明的类型。

尽管由于这显然与设计目标背道而驰，但我可能不会屏住呼吸-我们现在必须与unknown有关。

您是否看到打字稿面临其他任何问题，或者您不同意其中的一些？ 到达 @GeeWengel

From: https://hackernoon.com/4-future-challenges-for-typescript-e3ae90563d7e