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.

[evanw]

Is it planned for this to work with TypeScript types as well as values? For example, I'd expect the following to be valid as well:

import type { 'a' as b } from 'foo' 
import { type 'a' as b } from 'foo' 

export type { a as 'b' }
export { type a as 'b' }
export { type 'a' } from 'foo' 
export { type 'a' as b } from 'foo' 
export { type a as 'b' } from 'foo' 
export { type 'a' as 'b' } from 'foo' 

I'm wondering because esbuild supports both TypeScript and arbitrary module namespace identifier names, so it has to deal with this somehow. Right now I'm moving forward assuming that it will eventually be supported for types as well but it would be good to clarify this.

[andrewbranch]

@evanw I’m pretty sure your examples above will “just work” unless we explicitly disallow them, and I don’t see an immediate reason to do that. The syntax above would certainly parse. Just out of curiosity, what’s the impact of this on esbuild?

[andrewbranch]

@DanielRosenwasser should this actually be milestoned right now? It’s a bit hard to tell the status of the spec change, but it looks kinda stuck.

[DanielRosenwasser]

Good call, I assumed it would be an open-and-shut normative PR but it looks like it hasn't been updated for a while; let's hold off until tc39/ecma262#2154 is actually merged.

[Jack-Works]

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.