Consideration: starting with a "default namespace" instead of protected specifiers

[SMotaal]

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:

1. for code to conditionally adapt — common and very useful

   e.g. 'object' === typeof process && process && … (a little rough imho)

2. dynamically initialize namespaces — less common and very useful

   e.g. repl in Node.js: > fs. then tab… etc.

3. 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 // false
if (process) process.exit(); // bye

// Assuming platforms want to lazy load extensions
import global;
global.dynamicThing // where export default { async get dynamicThing() { … } }

// How about having verbose syntax (if needed)
import default { Object };

// Does this need to be top level (maybe not!)
export async function saveToDisk(…) {
    import default { fs, chrome };  // I personally prefer top-level
    if (chrome) {
        …
    } else if (fs) { 
        …
    } else {
        throw Error(`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.