Stage 2 tracking

[mattijs]

This proposal reached stage 1 at the July 2018 meeting and this issue will track progress towards stage 2.

Requirements:

• Initial spec text
• Major syntax and semantics
• Document several motivating use cases
• Transfer this repo to the TC39 org

[ljharb]

Before stage 2 advancement, I believe this proposal needs to answer these unanswered questions:

1. How can i synchronously access a built-in module in Scripts? (import() is not sufficient) (related: Implementation details #41 (comment),
2. How can I, in the language alone, add (polyfill/shim), mutate (repair bugs), delete (deny access to, perhaps for security), built-in modules? (import maps are not in the language) (related: Reliably accessing built-ins from standard library polyfills #13, Polyfilling modules #2)

[mattijs]

@ljharb good questions, I'll look into answering them

[ljharb]

There's additional information that's relevant to this proposal in this thread: tc39/ecma262#395

I wasn't sure where to link it :-)

[msaboff]

2. How can I, in the language alone, add (polyfill/shim), mutate (repair bugs), delete (deny access to, perhaps for security), built-in modules? (import maps are not in the language) (related: Reliably accessing built-ins from standard library polyfills #13, Polyfilling modules #2)

Certainly we need the ability to provide a means for a fallback implementation for missing built-in modules. There is possible the case for a built-in module with a known bug. @ljharb, please describe in more detail the other polypill use cases.

[ljharb]

• Adding functionality to an engine that didn’t exist in the spec until after that version shipped whether that’s a new builtin module entirely (like Temporal, say), or patching an existing module with new functionality (like a new Temporal method)
• patching broken functionality, which sometimes means replacing/wrapping a method, and sometimes means replacing/wrapping the entire feature
• preventing access to potentially unsafe capabilities, like network/fs access, high precision timers, user data, etc - by replacing, patching, or removing a module

and even, adding my own custom module for, for example, importing all my company’s internal modules without needing to use URLs (something import maps allows in the one browser it’s in)

[msaboff]

• Adding functionality to an engine that didn’t exist in the spec until after that version shipped whether that’s a new builtin module entirely (like Temporal, say), or patching an existing module with new functionality (like a new Temporal method)

The first part of this ones the missing functionality.

or patching an existing module with new functionality (like a new Temporal method)

Couldn't this be handled by creating your own module that imports the builtin Temporal, subclasses it and then exports the subclass as Temporal?

• patching broken functionality, which sometimes means replacing/wrapping a method, and sometimes means replacing/wrapping the entire feature

This is handling a known bug case. This could be handled with a package name map like functionality and then providing a module that imports the builtin, subclasses and fixes it and then exports the subclass.

• preventing access to potentially unsafe capabilities, like network/fs access, high precision timers, user data, etc - by replacing, patching, or removing a module

This is a specific instance of the "known bug" case.

and even, adding my own custom module for, for example, importing all my company’s internal modules without needing to use URLs (something import maps allows in the one browser it’s in)

I think that capability is beyond the scope of this proposal.

[ljharb]

Re subclassing/wrapping, I can certainly do that, but the point is that i want all dependencies - code i don’t control - to get my version of Temporal, and to prevent any access to the original one.

Similarly, by fixing, i need code that doesn’t know about the bug or my fix to silently get my fixed version when they ask for the original one, just like i can do now with globals.

The last part may be directly beyond the scope of the proposal, but i think it falls out naturally from the other requirements, which imo are both in scope and also stage 2 requirements.