Reliably accessing built-ins from standard library polyfills

[littledan]

@domenic 's get-originals proposal provides a mechanism for reliably accessing built-ins. There is another suggestion to do this via built-in modules.

Get-originals is proposed as a web platform API, but this capability could be useful across multiple JavaScript environments. Should we make get-originals available across JavaScript environments, try to pursue something as part of this proposal (as @mattijs suggested), or both? What requirements do we have on a mechanism like this?

[bakkot]

I would like to say that there's a requirement that early-running code can virtualize "originals" from the perspective of late-running code. See domenic/get-originals#18 for justification.

Note that I don't believe import-maps would be sufficient for this if builtin modules were deeply frozen, at least as I understand that proposal, because defining or overriding import maps would not be a power programmatically available to early-running JavaScript code.

[littledan]

@bakkot Is import-maps sufficient in its current state, if get-originals were, itself, exported from a module that could be virtualized?

[bakkot]

@littledan By "could be virtualized", do you mean "by import-maps" or "by JavaScript code"? If the former, no. If the latter, I think yes.

[littledan]

@bakkot The virtualization would be a combination of import-maps and JavaScript code, right?

[ljharb]

Are import maps planned to be part of the language along with builtin modules?

[bakkot]

The virtualization would be a combination of import-maps and JavaScript code, right?

If early-running JS code cannot programmatically modify import-maps, then no, that would not be sufficient.

Specifically: it is currently the case that a library A can redefine, for example fetch, with the effect that including this library on a page before other JS will cause all other JS on the page to see A's fetch rather than the original. A lot of the web depends on this being the case. If library A can, in JavaScript, modify import-maps for the page on which it is running such that other code on the page which imported the "get built-ins" module would get A's version of fetch from that module, JS + import-maps would be sufficient. If it can't, it would not.

[littledan]

@ljharb Not currently. Let's discuss that issue in #2 . My view is that we can be flexible about standards venue as long as there's a good solution available to JavaScript implementations that want to support virtualization (which presumably would include the Web and Node.js).

@bakkot The current import-maps specification lets scripts that run before any module insert import maps. See https://github.com/domenic/import-maps#dynamic-import-map-example for an example.

[bakkot]

@littledan Ah! I'd missed that, thank you. I believe that could be enough, yes, though I'd need to think more about it to be sure. (Part of the problem is that import-maps doesn't lend itself very well to wrapping modules, as opposed to just replacing them.)

[littledan]

The more I think about it, the less I understand how we could possibly make the built-in modules that always have the original values/a frozen copy work. Has anyone thought through what the semantics should be?

At the same time, the get-originals proposal (if it were a built-in module, so it's virtualizable but you have a central point of control which is the import-map) seems like a good solution. As far as WebAssembly goes, I don't see why get-originals wouldn't work well for that either.