Repository navigation
Support “Arbitrary module namespace identifier names” #40594
Description
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
// @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";Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
Activity
ExE-Boss commentedon Oct 22, 2020
Note that Babel now has support for this: babel/babel#12091
DanielRosenwasser commentedon May 9, 2021
tc39/ecma262#2154
The above code should be supported.
The minimum viable product should have tests for:
esnextmodule outputes2015or similar module output just to get an error--declarationemitimport()type syntax.import()type syntaximport {}andexport {}listsIt is likely that we would never try to emit our own
import()type syntax.31 remaining items
fix: invalid names in import object (#30)
Jack-Works commentedon May 15, 2023
Some progress: I recently rewrite PR for this issue. I also plan to include full support (checker, transpiler, and language service).
I'm still working on it.
feat: Support named exports
evanw commentedon May 24, 2024
(For those on this thread) I gave fixing this a try: #58640
Jack-Works commentedon May 24, 2024
I'm happy to see you pick this up! My mental health does not support me finishing my PR for now but I still want to see this happen
DanielRosenwasser commentedon Jun 7, 2024
Thanks Evan Wallace (@evanw)!
evanw commentedon Jun 8, 2024
Thank you for accepting this PR. I'm looking forward to using this feature in VSCode!
One potential remaining task is syntax highlighting. I have another PR ready to go that adds support for this feature to the TypeScript language syntax definition: microsoft/TypeScript-TmLanguage#1030. Would it be possible to add that or a similar change (doesn't have to be mine) so that syntax highlighting works too?