JavaScript Standard Library Proposal (Builtin Modules)

[annevk]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Standard Library Proposal
• Specification or proposal URL: https://github.com/tc39/proposal-javascript-standard-library/
• Mozillians who can provide input (optional): @lukewagner @tschneidereit @linclark @callahad

Other information

This is what #145 and #146 build on, somewhat. A concern I've seen is that they don't block on this though as all the infrastructure could be moved outside "TC39 control".

[domenic]

Note that tc39/proposal-built-in-modules#43 may be clarifying. In terms of actual normative work this is proposing, there is none yet from the proposal champions, but I've put together tc39/proposal-built-in-modules#44 which represents one direction the champions maybe-possibly might be interested in.

[littledan]

To summarize some of the issues under discussion:

• Polyfilling/virtualizing built-in modules Polyfilling modules tc39/proposal-built-in-modules#2
• The prefix for built-in module specifiers could be of the style @std/, std:, std::, or something else.
• All JS/Web built-in modules could be in one namespace, or they could be in multiple. Split or unified namespaces? tc39/proposal-built-in-modules#14
• Built-in modules could be deeply frozen Should built-in modules be deeply frozen? tc39/proposal-built-in-modules#15
• There have been various suggestions of defining module resolution or polyfilling in the JavaScript specification.

TC39's most recent discussion was at the November 2018 meeting in a breakout session, see notes. The notes are pretty high-level, but we discussed each of those issues listed above.

The current import-maps/kv-storage origin trial takes some opinions on these questions:

• Polyfilling is provided via import-maps.
• Module contents are not deeply frozen.
• As the module prefix, std: is used.

Current specifications and drafts layer the module map, module resolution and polyfilling in HTML (or WebIDL to potentially populate the module map); I haven't seen a concrete technical proposal for putting any of these in the JavaScript specification.

I'm not a big fan of focusing on "TC39 control"; let's just work together towards a common path for built-in modules coming from TC39 and Web APIs, integrating input from web developers and people working in various standards bodies.

[dbaron]

also cc @bholley

[annevk]

Thanks Daniel for that summary. We’ve discussed this internally and of the unresolved issues in TC39 we feel most strongly about having a single namespace for standardized APIs.

There’s precedent of APIs moving between standards bodies (ArrayBuffer) and precedent of APIs being shared across ecosystems (URL, TextDecoder, etc. can be found on the web and in Node.js).

The alternative would involve aliasing or worse, ending up with slightly different flavors of the same thing.

Ideally the governance is such that a name is not permanently allocated unless there’s commitment from multiple implementers, a standardized API, and a sufficiently large test suite.

(This should not preclude other ecosystems from having their own namespace.)