search

wintercg / proposal-common-minimum-api

https://common-min-api.proposal.wintercg.org/
Other
227 stars 13 forks source link

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

Open maxshirshin opened 2 years ago

maxshirshin commented 2 years ago

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 commented 2 years ago

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

maxshirshin commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

maxshirshin commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 1 year ago

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.