Support “Arbitrary module namespace identifier names”
See original GitHub issueSearch 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 https://github.com/tc39/ecma262/pull/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 https://github.com/tc39/ecma262/pull/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";
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
Issue Analytics
- State:
- Created 3 years ago
- Reactions:4
- Comments:13 (11 by maintainers)
Top Results From Across the Web
1670044 - Allow Arbitrary module namespace identifier names
Bug 1670044 - Part 1: Implement "Arbitrary module namespace identifier names" proposal. r=yulia! 2 years ago. André Bargull [:anba].
Read more >Huáng Jùnliàng (黃俊亮) on Twitter: "You can try it out on https ...
Babel 7.12 will support ES2021 arbitrary module imports ... Normative: Arbitrary module namespace identifier names by bmeck · Pull Request ...
Read more >TC39 meeting, September 21-24 2020 - SpiderMonkey
Arbitrary module namespace identifier names ... Proposal Link; Summary: Support proper ergonomic brand checks for classes.
Read more >API - esbuild
For example, TypeScript's JavaScript parser may not support arbitrary module namespace identifier names so you may want to turn those off when targeting ......
Read more >evanw/esbuild v0.12.27 on GitHub - NewReleases.io
This release marks this feature as supported in Edge 89, Firefox 89, ... They have recently added support for arbitrary module namespace identifier...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@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?
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:
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.