Support “Arbitrary module namespace identifier names”

[ExE-Boss]

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:

• 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.

Related issues

• Allow Unicode string imports and exports #43870
• Normative: Arbitrary module namespace identifier names #49297

[ExE-Boss]

Note that Babel now has support for this: babel/babel#12091

[DanielRosenwasser]

tc39/ecma262#2154

import { "😊" as yay } from "...";

yay();

export { yay as "🦈" };

The above code should be supported.

The minimum viable product should have tests for:

• esnext module output
• es2015 or similar module output just to get an error
• --declaration emit
  • Specific declaration emit where the compiler might generate import() type syntax.
• Quick info, and error message tests where we might generate import() type syntax
• Completions in import {} and export {} lists
• Go-to-definition

It is likely that we would never try to emit our own import() type syntax.