Std: If you build it, they will come!

Safe Modules
#1

Update: I must admit my fault in over-generalizing my conclusions, that said, my position regarding import maps being the solution for builtins where every library (assuming a world without the need of bundlers per intent) will be baked with some builtin-polyfill mapping following some convention — that redundancy does not belong in the module map that is used to bootstrap all the things.

Note: For those interested, I think this is the relevant place for staying in the loop, see Appendix A. Distinguishing Standard Library Modules in JavaScript Standard Library Proposal

So not sure if you guys saw this: https://developers.google.com/web/updates/2019/03/kv-storage

I am posting this cautiously here because while dropping scoped access to globals is a premise I am working off towards the realization of safe modules, doing it wrong is going to make this backfire!

While you read the kv-storage post, make sure you read the portion addressing import maps and then read import maps. How much thought would it take for an author blogging in such a venue to come to the realization that import maps will most likely not support “std:” or standard scheme prefixes — which is may be not explicitly stated yet — because import maps cannot ever be allowed to shadow select URLs (ie inject code with an otherwise trusted certificate of authority). So, let’s say I am wrong, did they even consider testing their claim for polyfilling :frowning: in other browsers.

While I am not ready to defend dynamic namespaces, it is exactly these kinds of proposal theatrics that make people demand features before they are thought out and while they are too untenable and impossible to properly test their validity as experimental candidates on more critical aspects like security and future-adequacy.

I wanted to see what everyone else thinks about all this while I slowly work to present you with a more complete and adequately comprehensive way to do away with the unsecure aspects of global scope in code that does not need it — ie and allow legacy to be legacy (mostly).

#2

Example

In this example, an import map is used to override the third-party module “login”. Which is used by accounts. The question is, can the following be problematic?

JS https://your.vault/services/accounts.js 
import {login} from '../apis/login.js';
import {token} from '../apis/jwt.js';

if (token) {
  login(validateAccountToken(token));
}

async function validateAccountToken(token) { /* some logic */ }
HTML https://my.vault/index.html 
<script type=importmap>
{
  "https://your.vault/apis/login.js": "/fake-login.js"
}
</script>

If this scenario is not problematic, then the argument against URL mapping is void. Please share your thoughts.