Supporting browser stdlib fallbacks

[guybedford]

Now that we have the browser stdlib shipping, it's worth thinking about how this proposal can facilitate these polyfill fallbacks.

One way to do this might just be to support array fallbacks as @jkrems has previously suggested, to simply align with import maps.

Then an example workflow would be (and note how this builds on #30):

{
  "exports": {
    "kvstore": ["std:kvstore", "kvstore-polyfill"]
  },
  "dependencies": {
    "kvstore-polyfill": "1.2.3"
  }
}

We then use import 'kvstore' in the actual code to get the polyfill in Node and browsers without support, as well as getting the builtin module fallback working out.

In addition the polyfill is a shared library that doesn't have to be duplicated between packages.

The thing we would need to do though is define how these fallbacks work in Node.js... which isn't completely clear currently.

In the browser the fallback does not support http/https fallbacks for not found errors etc. Rather, it is just a fallback of std: specifiers currently.

Do we just make Node.js just always skip std: specifiers? Then if/when it adds any std: support to align with browsers we do the same thing as browsers?

Does this mean that Node.js std libs can have similar fallbacks with node: style usage? Does this provide a similar workflow for future nodejs builtins?

Would such a mechanism extend to our conditional needs?

[guybedford]

To be super clear, the above generates the import map:

{
  "scopes": {
    "/path/to/pkg": {
      "kvstore": ["std:kvstore", "../kvstore-polyfill/index.js"]
    }
  }
}

[jkrems]

One challenge is the fallback ordering / setup and another is the "chained import resolution". E.g. having a mapping ["std:kvstore", "kvstore-polyfill"] implies recursion because kvstore-polyfill has to be looked up using the same process again (import:-to-import: mapping). Unless I'm missing something. :)

[guybedford]

@jkrems I'm glad you're considering these things, but this isn't a problem - recursion is avoided by separating the LHS and RHS spaces entirely as import maps do now thankfully. Effectively the LHS is in a prealias space, while the RHS is in the pre-node_modules lookup space. Definitely an important concept in having these resolver state transitions moving towards convergence and not recursion as part of ensuring all is well-defined.

[jkrems]

The example I had in mind is:

/deps/a/package.json
  { "exports": "b" }
/deps/b/package.json
  { "exports": "a" }

Or is the assumption that bare values are only allowed for bare keys..? I think I'm starting to lean towards splitting "imports" and "exports" into 2 different keys, at least if the rules for their interpretation will differ. Although at that point imports may just become a weird duplicate dependencies field:

{
  "exports": "./b.js",
  "imports": { "x": ["std:x", "x-polyfill@^2.0.0"] }
}

but only semi-.

[guybedford]

Yes bare values cannot be RHS targets for relative imports to ensure a well-defined scheme. Splitting them up may well make sense especially given the different RHS semantics. It is nice to have them in the same spec object though for covenience both of spec authoring and usage, as I don’t personally find it confusing having them in the same object since they are well disambiguated and this matches the browser field cowpath.

…

On Wed, 13 Mar 2019 at 18:30, Jan Olaf Krems ***@***.***> wrote: The example I had in mind is: /deps/a/package.json { "exports": "b" } /deps/b/package.json { "exports": "a" } Or is the assumption that bare values are only allowed for bare keys..? I think I'm starting to lean towards splitting "imports" and "exports" into 2 different keys, at least if the rules for their interpretation will differ. Although at that point imports may just become a weird duplicate dependencies field: { "exports": "./b.js", "imports": { "x": ["std:x", "x-polyfill@^2.0.0"] } } [image: ] but only semi-[image: ]. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkiymmK7r4YIm9DWgGivt0YRGQzg4pSks5vWSeygaJpZM4btbrH> .

[jkrems]

I think this gets replaced by either the polyfill having the fallbacks in its exports or the app using imports. Should we close this?

[guybedford]

Yes it seems like the conversation here has moved on.