Runtime's own key resolution should be at least somewhat defined

[panva]

This is very much related to #5, it highlights its importance and issues in the module ecosystem stemming from runtimes such as Bun and Deno pretending to be Node.js

From the very example in the proposal

"exports": {
    "node": "./dist/node/index.js",
    "deno": "./dist/deno/index.js"
},

or an extended one

"exports": {
    "node": "./dist/node/index.js",
    "deno": "./dist/deno/index.js",
    "bun": "./dist/bun/index.js"
},

While lacking resolution for #5 and at least some prescribed lookup behaviour one would mistakenly think that the following means "everything but node loads from the webapi dist".

"exports": {
    "node": "./dist/node/index.js",
    "default": "./dist/webapi/index.js"
},

Unfortunately that is not the case. Only Node.js correctly loads its intended export, while both Bun and Deno load "node" in all three examples above because of their compatibility beliefs and undescribed key order matching (all runtimes just look from top to bottom for a first hit).

I believe the proposal needs #5 combined with at least some text around how the keys are to be used.

For example:

• add "wintercg" or similar which effectively behaves as "default" does in the Node.js resolution algorithm
• prescribe that runtimes must first look for their own key, then wintercg/default, and only then fallback on proprietary resolution algorithms

The alternative (today's behaviour) is that module authors need to maintain an ever growing list of keys in their package.json on the offchance that a new runtime is added that inherits from Deno or Bun in that they believe they can work with "node" exports