JSDoc + IDE 与 TypeScript答案

【问题标题】：JSDoc + IDE vs. TypeScriptJSDoc + IDE 与 TypeScript
【发布时间】：2021-09-26 00:24:23
【问题描述】：

使用正确维护的 JSDoc，几乎所有现代 IDE 都可以识别类型不匹配（赋值、函数的签名/参数）以及非强类型语言引入的许多其他问题。
除此之外，现代 JS 还具有可预测的变量范围、无提升行为、模块化、内置类支持等等。

TypeScript 在哪些场景下比 JS+JSDoc 更能满足开发者的需求？

注意事项：我说的是强制支持旧版 JS/浏览器并且 TS + Babel 可以将现代代码库转换为一些对旧版友好的环境的情况。

【问题讨论】：

JSDoc 似乎能够模拟 typescript 的作用，但是代码中有这么多 cmets 会使实际代码不可读。
@Boug，JSDoc 类型可以在单独的 JSDoc 字典中定义，而在代码本身中只会出现引用，就像被视为标准的 JavaDoc 一样。
我可以很容易和意外地与 JSDoc 撒谎。 TS让我不得不更有目的地说“我比你更了解TS，这绝对是一个数字，我不在乎你是否有其他想法”。 JSDoc 恰恰相反，你必须总是说某事是什么。
我试图让问题更清楚。 “注释”混淆了原始问题，实际问题被问了两次，只是措辞不同。
我投票支持重新开放，看看你是否可以进一步改进。

【解决方案1】：

Typescript、Closure等各种Js编译器正式支持使用JSDoc进行类型检查https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html

如果要键入检查Js源代码，这是一个有效的选项。

【讨论】：

【解决方案2】：

我认为这种比较有点奇怪。 JSDoc 是面向文档的，而 typescript 为 js 添加了可选的静态类型。这些工具确实有一些共同点，例如它们允许进行类型检查，但它们的用途不同。

不过，这是一个有趣的问题。我想鼓励大家就这个话题展开讨论，所以我将谈谈我使用这些工具的经验。

我对 jsdoc 的主要问题是以下部分至关重要：

妥善维护的 JSDoc

jsdoc 对自动完成的有用性直接取决于 jsdoc cmets 的工作量和质量。我发现很难在大型项目中执行。复杂的类型/接口也很难描述和维护，非常冗长。而ts比jsdoc简洁很多。

此外，ts 中的类型和接口是一等公民，而不仅仅是为了文档而添加的。它们是源代码中的实体，可以导出以供其他模块使用。在编译过程（和之前）中强制执行类型不匹配。还有像generics或decorators这样的机制，都是ts自带的。

回到执行指南部分。使用 ESLint，您可以设置灵活的规则，允许您为您的类型微调限制/样式/指南。你想要严格的静态类型吗？还是要宽大处理？
如果需要，您可以强制执行您的确切需求并将其连接到 ci/cd。在我看来，在从事大型项目时，这是一个很大的好处。

工具也是一个重要因素，jsdoc 和 ts 都足够成熟，可以在它们周围建立生态系统。虽然在这个时间点jsdoc isn't an active project，但 ts 非常受欢迎，并且有一个庞大的社区围绕它进行大量活动。

所以这一切都取决于您的需求，如果您对 jsdoc 可以为您做的事情感到满意并且文档是您的主要关注点，那么 ts 不会为您做太多。

附： Ts 和 jsdoc 不是相互排斥的。您可以同时拥有两者，尽管您可能想切换到类似TSDoc

【讨论】：