issues with package.json exports resolution

[panva]

Refs: wintercg/runtime-keys#5
Refs: wintercg/runtime-keys#18

One can easily believe that the following exports condition examples mean "everything but node loads from the webapi dist".

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

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

Unfortunately Bun will load the "node" condition in both examples above despite there being a default or, even worse offense, an explicit "bun" one.

[panva]

Bottom line: As a module author I want to be able to write a module that exports "for node" and "for everything else" with two simple package.json exports. However the non-Node runtime's behaviour are in the way of being able to do that.

[RiskyMH]

"Whichever one of these conditions occurs first in the package.json is used to determine the package's entrypoint."
https://bun.sh/docs/runtime/modules#importing-packages

My understanding is you should put the "bun" condition above node and then bun will prefer it. However, I do agree it can get confusing sometimes and if bun just looked for its condition first then it could make more sense.

[panva]

@guest271314 there are very valid reasons for module authors to want to run native node APIs in Node and Web APIs elsewhere. Hence the separation of node and "everything else". Just because you don't see the reason and need doesn't mean it is there.

I will not get into the marketing false claims about node compatibility here.

NB: experimental-default-type does nothing on this regard and if statements in the code increase bundle sizes with dead code for other than the intended runtime that can have its own bundle.

[panva]

Why are you advocating for willing module authors not supporting bun when they can?

We're in this mess because of broken compat claims.

I am able to publish modules that work in web api runtimes as well as node (and older node without the web apis) all the same. All i ask for is that i don't have to enumerate every non-node runtime (a list of which is never final) in the package json and instead have the ability to provide a node-specific build and one target for non-node runtimes.

Today I can only do that if i keep on extending the package exports with every month's favourite new runtime flavour. 👎

[panva]

This is not about the module CJS/ESM type flavour.

[panva]

Then kindly explain precisely what you are talking about.

I did.

#15053 (comment)

If you write your modules a different way and can't accept that others might have different ways of thinking of how interoperable modules should be structured, that's fine too

[Jarred-Sumner]

@panva i'm sorry we haven't fixed the node:crypto bugs blocking the "node" target in Jose from working in Bun properly yet. We aren't going to change the decision to support the "node" condition, as in most cases it is better than the alternatives

If you want to force Bun to use the web api version, you can put an additional "bun" condition before the "node" condition and Bun will respect it

We will work on node:crypto more in about a month I expect

[panva]

@Jarred-Sumner thank you for thoughts. FWIW the issue here isn't necessarily about the jose module hardship, but rather about improving the situation for module authors.

Would you support the proposal from wintercg/runtime-keys#18?

I believe the proposal [wintercg/runtime-keys] needs wintercg/runtime-keys#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

This would not encoach on the runtime's ability to still target "node" as the proprietary resolution algorithm path.