建议
🔍 搜索词
在创建此问题之前,您搜索的关键词列表。在这里写下它们,以便其他人更容易找到此建议并提供反馈。
export =, type
✅ 可实现性检查清单
我的建议符合以下准则:
- 这不会对现有的TypeScript/JavaScript代码造成破坏性的更改
- 这不会改变现有JavaScript代码的运行时行为
- 这可以在不根据表达式的类型发出不同的JS的情况下实现
- 这不是一个运行时特性(例如库功能、JavaScript输出的非ECMAScript语法、JS的新语法糖等)
- 此功能将与 TypeScript's Design Goals 的其他部分一致。
⭐ 建议
即使已经包含一个 export =
语句的TypeScript文件,也允许 export interface
和 export type
。
📃 动机示例
参考此Playground,TypeScript当前会发出错误。
以前,社区严重依赖 "esModuleInterop": true
使作为ESM预期导入的CommonJS模块,但是随着Node的原生ESM解析(nodenext
模块解析),一个 export default
被转换为 exports.default
,这很难轻松导入:
import fooExports from 'foo';
// Actually it is default.default
const foo = fooExports.default;
为了摆脱这种丑陋且冗余的使用,社区可能比以前使用 export =
更多,但然后我们无法将其与类型一起导出。
💻 用例
对于任何希望编译为 module.exports
但同时导出一些类型的包,这是一个必须具备的功能:
export interface Options {
x: number;
y: number;
}
export = function add({x, y}: Options) {
return x + y;
};
2条答案
按热度按时间fnx2tebb1#
yhxst69z2#
我将这个功能作为必需的功能进行支持。在没有它的情况下,我很难找到创建一个类型良好且可互操作的公共接口的最佳方法。