🔍 搜索词
jsdoc module.exports
✅ 可实施性检查清单
我的建议满足以下准则:
- 这不会对现有的TypeScript/JavaScript代码造成破坏性的更改
- 这不会改变现有JavaScript代码的运行时行为
- 这可以在不根据表达式的类型发出不同的JS的情况下实现
- 这不是一个运行时特性(例如库功能、JavaScript输出的非ECMAScript语法、JS的新语法糖等)
- 这个特性将与 TypeScript's Design Goals 的其他部分保持一致。
⭐ 建议
为 module.exports
添加一个 @type
的JSDoc注解,使其在其他上下文中进行类型检查。
📃 动机示例
目前,给定以下 blah/some-type.ts
:
export default interface SomeType {
name: string,
age: number
}
...这不会进行类型检查:
/** @type {import('./blah/some-type').default} */
module.exports = {
name: 0,
age: 'forty-three'
};
...但是,通过一些额外的步骤,这可以进行类型检查:
/** @type {import('./blah/some-type').default} */
const obj = {
name: 0,
age: 'forty-three'
};
module.exports = obj;
这与 #27327 相似,但像在 module.exports
中添加一个 @type {string}
这样的简单事情确实有效。导入的类型不起作用。
💻 用例
我们有一个CommonJS JS配置文件,我们希望用户能够对其进行类型检查。你认为应该添加类型注解的预期方法并不起作用。
2条答案
按热度按时间kgsdhlau1#
我已经遇到了同样的问题,只是细节不同。
在 TypeScript 4.9.5 中,使用导入的类型输入
module.exports
是没问题的,只要文件不包含 JSX 语法。这个
gatsby-browser.jsx
类型会检查:但这个不会:
解决方法与 OP 相同。
jxct1oxe2#
看起来这个问题也与我在这里的问题类似:
$x_1e^{0}f_1x$