Detailed feature-testing within modules

[littledan]

In tc39/proposal-built-in-modules#2 , some maintainers of widely distributed libraries/polyfills chimed in and noted their desire to do things in between the space of "use the built-in module" and "entirely replace it", in order to provide a reliably up-to-spec environment on all browsers (e.g., see tc39/proposal-built-in-modules#2 (comment)). For example,

• Patch on individual methods to classes when they are missing
• Check for known bugs that were shipped in past browsers and replace/wrap functions to fix them

As far as I can tell, these can all be accomplished through import-maps with the wrapping a built-in module idiom, possibly with the help of top-level await as in Alternating logic based on the presence of a built-in module.

Anyway, although this is a fine technical solution to give parity with patterns used on the current web, I'm not extremely excited for this to proliferate in a built-in modules+import-maps world: import-maps has the potential to reduce the volume of polyfill code shipped over the wire to new browsers, but if this pattern catches on, we're back at square one, with a large volume of feature-testing and polyfill code dynamically sent over the wire and executed at startup, even for browsers that don't need it.

I wonder if, possibly as a v2 or separate proposal, it could make sense to allow import-maps to have access to more advanced feature tests that would reduce the need for shipping this sort of code to newer browsers. Designing such a feature testing API is a big endeavor, though; I don't have one to propose, just vague ideas.

If import-maps will never have such a feature testing API, this may influence the design of APIs exposed through built-in modules. For example, maybe they would adopt a pattern of keeping each module smaller, so that the presence of various components can be individually feature-tested for via import-maps, reducing the potential overhead of partial polyfills.

[Pauan]

For example, maybe they would adopt a pattern of keeping each module smaller, so that the presence of various components can be individually feature-tested for via import-maps, reducing the potential overhead of partial polyfills.

A pattern used in many languages (including Rust and npm) is to publicly expose tiny modules, and also expose a module which re-exports all the tiny modules:

// some-library/foo.js
export const foo = ...;

// some-library/bar.js
export const bar = ...;

// some-library/index.js
export * from "./foo.js";
export * from "./bar.js";

This gives the best of both worlds:

• Users can import individual modules if they want to (which can help with tree shaking).

  Or they can choose to import the single index.js file, which is much more convenient.

• Import maps can override specific modules.

It seems like this would be a win today, even with current technologies (Webpack, Rollup, etc.), and it has the potential to solve various issues with built-in modules, so perhaps it would be good to explore this option in more depth.

[guybedford]

This is a super complex space we were also trying to discuss at jkrems/proposal-pkg-exports#29. I tend to think that things are a little different today while we rely on globals, and that once builtin modules become the norm, "polyfills" as a concept entirely shift to simply being builtin fallbacks.

[littledan]

I think it'd be good to think about this feature ahead of time, as it affects what sorts of conventions make sense in built-in modules. Some very early thoughts on this at https://github.com/littledan/import-map-feature-tests/blob/master/README.md

[domenic]

With the removal of built-in modules support, and fallbacks in general, in #176, this is no longer applicable, so I'll close it out.