Flowtype-是否有任何理由不将所有node_modules放入[declaration]? [英] Flowtype - is there any reason not to put all node_modules in [declarations]?

问题描述

在升级Flow时，在 node_modules 中出现错误是很常见的，但这会使许多错误消失:

It's fairly common to get errors within node_modules when upgrading Flow, but this makes a bunch of errors go away:

[declarations]
<PROJECT_ROOT>/node_modules/.*

此外，我认为它大大减少了Flow必须处理的工作量，因为

Also, I assume it significantly cuts down on the amount of stuff Flow has to process, since

在声明模式下，不对代码进行类型检查.但是，在检查其他代码时，类型检查器会提取并使用函数，类等的签名.

In declaration mode the code is not typechecked. However, the signatures of functions, classes, etc are extracted and used by the typechecker when checking other code.

但这不是默认设置.有什么我不应该这样做的理由吗?如果类型签名本身有错误(例如，实现接口但方法类型不同的类，或者库和使用项目之间安装的流类型defs不同)，它将无法报告使用这些类型签名的代码中的某些错误吗?

Yet this isn't the default. Is there any reason I shouldn't do it? If the type signatures themselves have errors (like a class implementing an interface but differing in method types, or installed flow-typed defs differing between library and consuming project), would it fail to report some errors in my code that uses those type signatures?

我应该注意，因为AFAIK Flow still 没有工具只能从源代码*输出定义，我只是将整个源文件复制到 .js.flow在我们的许多内部软件包中.因此，在使用这些软件包的项目中升级Flow时会发生错误.但是，即使在我们当前使用的 graphql 版本中，我也看到过错误.

I should note because AFAIK Flow still doesn't have a tool to output definitions only from source code*, I've just been copying the entire source files to .js.flow in many of our internal packages. So errors occur when upgrading Flow in projects that use those packages. However I've seen errors even from within the version of graphql that we're currently on.

*当我尝试使用文档中提到的 print-signature CLI命令时，该命令实际上并不存在.

*The print-signature CLI command mentioned in the docs doesn't actually appear to exist when I try to use it.

推荐答案

使用 [declarations] 绝对有意义，要么相对于第三个版本，还是继续使用您的Flow服务器版本-party程序包，而不必完全放弃它的类型定义.

Using [declarations] definitely makes sense to either move forward or stay behind with your version of the Flow server in relation to some third-party package, without having to completely discard it's type definitions.

我一直在明确地提供可理解的路径，这些路径清楚地指出了导致问题的 [declarations] 中的程序包，因为这有助于提示需要注意哪些依赖性并优先考虑升级以获得更好的性能.可用时提供打字体验.

I've been explicitly providing intelligible paths that clearly denote packages in [declarations] which are causing issues, as this helped hint which dependencies to keep an eye out for and prioritize upgrades to get a better typing experience when it becomes available.

那是我认为您最终会真正失去的唯一一件事，就是准确知道您可能没有完整类型信息的依赖项的能力.

And that's I think the only thing you'd truly lose at the end of the day, the ability to know exactly for which dependencies you might not have complete type information.

这篇关于Flowtype-是否有任何理由不将所有node_modules放入[declaration]?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！