You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As critical as it is to introduce builtin modules in ESM, it is a very complicated thing and requires a lot of research as evident in your efforts. I have also looked into this problem space many times and was surprised that I missed this proposal and it was only brought to my attention yesterday when discussing globals in nodejs/modules.
I'd like to bring up the idea of a default namespace which has evolved out of several refinements starting from the idea of protected specifiers (like std:... etc) responding to the state of the ecosystem.
Historically, standard and platform API's were all exposed through the global object but node used require('…') to defer and/or avoid unneeded and sometimes expansive bootstrapping.
The global object makes it possible to:
for code to conditionally adapt — common and very useful
e.g. 'object' === typeof process && process && … (a little rough imho)
dynamically initialize namespaces — less common and very useful
e.g. repl in Node.js: > fs. then tab… etc.
polyfill — common
a. introduce missing named aspects — common
b. add missing functionality (on existing named aspects) — common
c. override non-compliant methods on existing named aspects — hopefully not
d. override non-compliant named aspects altogether — hopefully not
Default Namespace
While it is important to making progress towards modularized builtins, it is also important to divide the problem in ways that would allow this gradual transition to occur and still make it possible to accommodate all the existing trends built around the global object.
The idea of a default namespace is a way to start addressing the problem of globals without having to deal with the complexities of specifiers which would greatly impact module resolution not just for ESM loaders (all existing tooling).
Potential Uses
// Assuming undefined names don't throw (why not?!)import{Object,fs,process};!fs// true!process// falseif(process)process.exit();// bye// Assuming platforms want to lazy load extensionsimportglobal;global.dynamicThing// where export default { async get dynamicThing() { … } }// How about having verbose syntax (if needed)importdefault{Object};// Does this need to be top level (maybe not!)exportasyncfunctionsaveToDisk(…){importdefault{fs,chrome};// I personally prefer top-levelif(chrome){…}elseif(fs){…}else{throwError(`Unsupported …`)}}
This is the raw idea I am hoping to convey, which is not a substitute to having platform modules but is simply intended to help us get there.
The text was updated successfully, but these errors were encountered:
As critical as it is to introduce builtin modules in ESM, it is a very complicated thing and requires a lot of research as evident in your efforts. I have also looked into this problem space many times and was surprised that I missed this proposal and it was only brought to my attention yesterday when discussing globals in nodejs/modules.
I'd like to bring up the idea of a default namespace which has evolved out of several refinements starting from the idea of protected specifiers (like
std:
... etc) responding to the state of the ecosystem.Historically, standard and platform API's were all exposed through the global object but node used
require('…')
to defer and/or avoid unneeded and sometimes expansive bootstrapping.The global object makes it possible to:
for code to conditionally adapt — common and very useful
dynamically initialize namespaces — less common and very useful
polyfill — common
Default Namespace
While it is important to making progress towards modularized builtins, it is also important to divide the problem in ways that would allow this gradual transition to occur and still make it possible to accommodate all the existing trends built around the global object.
The idea of a default namespace is a way to start addressing the problem of globals without having to deal with the complexities of specifiers which would greatly impact module resolution not just for ESM loaders (all existing tooling).
Potential Uses
This is the raw idea I am hoping to convey, which is not a substitute to having platform modules but is simply intended to help us get there.
The text was updated successfully, but these errors were encountered: