Proposal: Conditional export maps

[guybedford]

I'd like to propose an extension to this proposal to support conditional mappings.

Currently in Node, the "main" is used as the conditional branch in resolution by having different main fields per-environment - "browser", "react-native", "electron", etc.

One limitation of these approaches (amongst others) is that they don't apply for subpath requires, which is exactly what the browserify "browser" field was designed to provide.

The suggestion is that various static condition names could be provided to selectively map both the main and subpaths based on environment conditions.

Conditions could be supported by allowing a mapping into a Condition instead of a simple string.

There are many ways to go about this, but as an illustrative example, consider:

{
  "exports": {
    "": {
      "browser": "./src/lib-browser.js",
      "node": "./src/lib-node.js"
    },
    "/subpath/": {
      "browser": "./src/browser/",
      "node": "./src/node/"
    }
  }
}

The above would support import "pkg" providing a different result between browsers and Node by respecting the exports mapping defined here.

Similarly import "pkg/subpath/x.js" can be routed to different target folders based on these environment conditions.

The list of conditions, would be basically exactly what the different names for "main" are today (except for "module" of course!).

I think these kind of possibilities are absolutely necessary for the platform, and this spec can open up some exciting opportunities here.

[jkrems]

This sounds similar to editions, in principle at least. I do like the use of engines better than the browser field. The browser field doesn't allow exposing different builds for different browsers and it also has some existing connotations from the top-level field.

Speaking of that top-level field, I did find it useful at times to overwrite files rather than entrypoints. So maybe this should be a resource override rather than a mapping?

[GeoffreyBooth]

This seems related to #13.

[guybedford]

This is not related to editions in that it is not trying to detect engine versions. Rather it is providing the environment information, but without versioning - browser / node / react-native / production / development / etc etc.

[guybedford]

@jkrems conditionally rewriting internal requires is interesting yes, but I would be weary of remapping relative specifiers.

[SMotaal]

I think exploring this further is worth it... I like the simplicity of it personally but from Geoffrey's dataset, here are all numbers for all fields that are path-like strings and are not a known non-path field:

Table

field	path-like	other	trends
browser	92	24
browser-dev	3
browser:es2015	1
cjs:main	1
dev:main	2
dev:module	3
es2015	19
esm5	6
esm2015	6
esnext	18	1
esnext:main	1
fesm5	6
fesm2015	6
filename	1
jnext:main	1
js:next	6
jsnext:main	295
jsxnext:main	1
main	933
main:umd	3
module	940
module-browser	1
module-dev	6
module:browser	3
module:browser-dev	3
module:modern-browsers	6	1
module:modern-browsers-dev	6	1
module:node	4
module:node-dev	4
modules.root	1
umd	2
umd:main	12

I wanted to do some trend analysis before sharing this table, but if exports can help bring harmony to this space by offering a good alternative for others to adopt, that would be a great success

[jkrems]

Let's redirect discussions around this to the proposal for handling differential mappings: https://github.com/guybedford/proposal-pkg-targets/issues