Document the expected level of JS modules support (or the lack thereof)

[maxshirshin]

Should the minimum API expect a certain level of JS modules support from a runtime?

Even if we agree on a module syntax to use (e.g. ES modules), the module resolution algorithms and URI formats are so runtime- and OS-specific that we're unlikely to reach a decent level of interoperability.

Therefore I suggest we explicitly state we don't expect a runtime to implement any JS module format by default; however, we should reserve all keywords/syntax which may be necessary to avoid incompatibilities (e.g. the use of require should be regulated).

[XadillaX]

I'd like to use bundle to instead of modules. That means using a single file without any import or require.

[maxshirshin]

Playing a devil's advocate: Modules can be (theoretically) useful to bring in certain optional runtime APIs which shouldn't be loaded by default because of e.g. performance/security reasons.

[XadillaX]

Playing a devil's advocate: Modules can be (theoretically) useful to bring in certain optional runtime APIs which shouldn't be loaded by default because of e.g. performance/security reasons.

You mean do not mount those built-in apis under globalThis?

[ljharb]

@maxshirshin so can globals; that’s how browsers typically do it (lazy-load globals on demand).

[maxshirshin]

You mean do not mount those built-in apis under globalThis?

Yes. This whole idea, however, doesn't make much sense unless we discuss e.g. a "JS standard library". So, I'm still convinced we shouldn't make module support a requirement.

[ljharb]

@maxshirshin theres a stalled language proposal for exactly that, and many have concluded that globals are the ideal standard library moving forward, so i wouldn’t hold my breath for something different.

[jasnell]

For now, I don't think there's anything we can codify as being a minimum common here but this is definitely something that should continued to be looked at ... perhaps eventually even its own workstream?

[guest271314]

Even if we agree on a module syntax to use (e.g. ES modules), the module resolution algorithms and URI formats are so runtime- and OS-specific that we're unlikely to reach a decent level of interoperability.

The last time I checked QuickJS, Deno, Bun, Node.js all support import.

For import to work using Node.js without package.json the extension needs to be .mjs.