TS的 @types - 类型定义完整指南 - 译文4

这是一篇Angular的课程文章，原文链接在此，我只做翻译。

文章看的懵懵懂懂，不是很了解在说什么，又感觉学到了点啥。

1.结论和建议

如果我们使用的是Typescript，我们有多个类型定义的来源，知道选择哪些类型定义以及为什么选择这些类型定义，对于能够有一个良好的开发者体验至关重要。

我们需要注意一点：编译器总是在增加更多的功能，但现有的库可能还没有利用这些功能。

我们什么时候应该使用编译器选择类型？

尽量使用编译器内置类型（lib标志）是个好主意，因为这些类型的编写是为了最大限度地保证我们程序的类型安全，确保我们符合标准API。

但根据现有库的现状，它可能会引入其他问题。当选择加入编译器内置类型时，一定要确保它们不会与我们之前已经导入的类型冲突，比如es6-promise，如果不需要的话，使用skipLibCheck也不会影响第三方类型。

但是不要觉得一定要使用选入类型，现在它们被默认关闭是有原因的，这是因为要向后兼容一部分现有的生态系统。

我们什么时候应该使用@types ?

与其系统地使用@types，不如尽量使用每个模块的内置类型，必要时战略性地使用@types，比如Express或Sequelize这样的模块。

像这两个普通的Javascript模块很可能会成为你程序的主体，并且在@types上有很好的类型可用。但比如像Firebase这样的新模块：它们现在已经带有类型了。

所以如果你也安装了@types/firebase，你会遇到重复的类型问题。

另一方面，像@types/node这样的东西对于编写任何node程序都是必不可少的。

所以这里的建议是：看看内置的类型，看看是否有类似于你正在寻找的东西。看看node模块本身是否已经有类型：这将会越来越常见。

如果既没有在模块内部找到类型，也没有在编译器中内置类型，那么看看@types中是否有一些好的类型。快进到未来，理想的情况是，@typesto不再存在，大多数库都有自己的类型定义。

但这不会很快发生，有这些高质量的类型在那里是很好的。

如果没有类型定义怎么办？

如果一个给定的库没有类型定义文件，也不会妨碍我们使用它。有了Typescript 2.1，我们可以直接导入库，任何导入的库都会被分配为any类型。

所以我们可以与任何现有的Javascript模块无缝集成，而不需要特别的集成。

如何确保我们的项目有效利用类型安全？

除了仔细选择我们添加到程序中的类型之外，我们可以做的最好的事情之一就是将noImplicitAny改为true。

这样做的效果是，编译器将能够推断出你程序中几乎所有的类型，而代价是只需要一些类型注释，尤其是在函数参数中，这无论如何都是一件很好的事情。