Search Terms
- Arbitrary module namespace identifier names
- Arbitrary module namespace identifiers
- Arbitrary module identifier names
- Arbitrary module identifiers
- Arbitrary module identifier
- Arbitrary export names
- Arbitrary export identifiers
- string export names
- string exports
Suggestion
Implement support for tc39/ecma262#2154.
Use Cases
This is necessary for WASM module integration.
This would also allow typing @types/webidl‑conversions without needing to use export =.
For transpiled modules, this can already be supported, since it’s just creation of arbitrary properties on the CommonJS exports object, but native modules will require module: "ESNext".
Examples
See tc39/ecma262#2154
// @showEmit
// @filename: module.d.ts
export const foo: unknown;
declare const some_imports: unknown;
export { some_imports as "some imports" };
declare const another_imports: unknown;
export { another_imports as "another imports" };
declare const extra_imports: unknown;
export { extra_imports as "extra imports" };
declare const rest_exports: unknown;
export { rest_exports as "rest exports" };
// @filename: index.ts
import { "some imports" as foo } from "./module.js";
export { foo as "some exports" } from "./module.js";
export { "another imports" as "another exports" } from "./module.js";
export { "rest exports" } from "./module.js";
export { "extra imports" as extra_imports } from "./module.js";
export * as "star exports" from "./module.js";
Workbench Repro
Checklist
My suggestion meets these guidelines:
Related issues
Search Terms
Suggestion
Implement support for tc39/ecma262#2154.
Use Cases
This is necessary for WASM module integration.
This would also allow typing
@types/webidl‑conversionswithout needing to useexport =.For transpiled modules, this can already be supported, since it’s just creation of arbitrary properties on the CommonJS
exportsobject, but native modules will requiremodule: "ESNext".Examples
See tc39/ecma262#2154
Workbench Repro
Checklist
My suggestion meets these guidelines:
Related issues