Support source phase imports

[dsherret]

🔍 Search Terms

import source wasm

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Support for source phase imports: https://github.com/tc39/proposal-source-phase-imports

• esm: Source Phase Imports for WebAssembly nodejs/node#56919
• feat: Add support for source phase imports denoland/deno_core#1081

📃 Motivating Example

// wasmModule is WebAssembly.Module
import source wasmModule from "./math.wasm"

💻 Use Cases

1. Getting a wasm module instead of instance.

[nicolo-ribaudo]

If anybody is going to work on a PR for this, it might be worth doing it on top of #60757 to avoid a ton of conflicts in the parsing logic.

[Jamesernator]

It would be good to make abstract module sources generic, especially for when sources support JS sources.

e.g.:

// mod.ts

export const name = "foo";

export function bar(): number { ... }

// mod has type ModuleSource<{ name: string, bar: () => number }>
import source modSource from "./mod.js";

// ... sometime later ...
const m = await import(modSource);

m.name; // has type string
m.bar; // has type () => number

For JS/TS/JSON the type of the module should already be available as it is today, ideally this would work with WASM as well but TS would need to parse wasm modules to find their types, alternatively we could have class WebAssembly.Module extends AbstractModuleSource<WebAssembly.Exports> if avoiding WASM parsing is really preferred.