TypeScript 在JSDoc中支持导入类型@implements

iqxoj9l9  于 4个月前  发布在  TypeScript
关注(0)|答案(1)|浏览(55)

建议

🔍 搜索词

@implementsjsdocimportexport

✅ 可实现性检查清单

我的建议符合以下准则:

  • 这不会对现有的TypeScript/JavaScript代码造成破坏性的更改
  • 这不会改变现有JavaScript代码的运行时行为
  • 这可以在不根据表达式的类型发出不同的JS的情况下实现
  • 这不是一个运行时特性(例如库功能、带有JavaScript输出的非ECMAScript语法、JS的新语法糖等)
  • 这个特性将与 TypeScript's Design Goals 的其他部分一致。

⭐ 建议

我们正在使用JSDoc注解在一个包中,以便我们可以避免构建过程,但仍然具有类型验证。我们发现当前的JSDoc支持非常实用,但有一个特定的场景不太理想。当我们想要声明一个类应该实现的接口时,我们使用 @implements ,但与其他标签不同,我们不能使用一个 import('..').Type 节点作为实现类型。这意味着我们必须事先使用一个 @typedef ,这并不可怕,但也从这个模块重新导出类型。对于常用类型,这会导致VSCode在尝试帮助您自动导入类型时给您的建议产生大量污染。
理想情况下,应该有一种方法可以为本地使用导入类型,或者 import().Type 语法应该被 @implements 标签支持。

📃 激励示例

SomeLog.ts

export interface SomeLog {
  foo(): void
}

Log.mjs

/** @typedef {import('./SomeLog')} SomeLog */

/**
 * @implements {SomeLog}
 */
export class Log {
  foo() { }
}

在这种设置下, SomeLogSomeLog.tsLog.mjs 中“导出”,这是不理想的,并导致意外地从错误的地方导入代码。

💻 用例

我认为我在建议中很好地解释了这一点。

lh80um4z

lh80um4z1#

我不认为有任何技术障碍可以允许

* @implements {import('./SomeLog')}

我记得在其他位置的解析器只消耗一个标识符/点分名称,但这主要是因为 implements 在普通类声明中的语法位置。在JS Doc标签中没有相应的问题,我们可以解析和评估任何合法的类型节点

相关问题