Do not add default `node`, `browser`, `require` or `import` conditions

I’m looking into using this module to implement support for exports in Jest.

Seems unfortunate that Node’s defaults should be forced on everybody using exports field. For a module that isn’t supported to run in Node, it should just fail to resolve or something (or falling back to default) not pick up node.

There’s already a switch in this library for browser condition so it’s not consistently enforced (at least from my understanding browser is just a thing Node acknowledges exists, nowhere in the spec does it say its presence removes the node condition) - why not just fully let the caller provide their own conditions (barring possibly default - that seems reasonable to always add)? I.e. remove the two allows.add calls (and maybe the options leaving only conditions). Or possibly add node if no conditions is passed, but otherwise add nothing.

As a datapoint, TypeScript could not have used resolve.exports to implement support for types condition with their official example: https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing since this module would have resolved import first.

I think resolve.exports should be implementation/host independent (maybe a resolve.exports-node or just a import { node } from 'resolve.exports' makes sense, but the base export shouldn’t put these limitations there).

Tl;dr: removing https://github.com/lukeed/resolve.exports/blob/c6814c43cb27ee6092f649be3fdf6c1fb55c51e4/src/index.js#L71-L72 would allow this module to be used by any runtime/host to implement exports support without getting Node semantics/conditions when the module might not even run in Node or a browser.

---

This is mostly a copy paste of https://github.com/yarnpkg/berry/pull/2431#discussion_r720221992.

[lukeed]

Released in 1.1.0~! Hopefully added enough warning labels for the general use case, but I guess time will tell 😆 Guess this means that TS could have used this now directly, although I’m sure they already have their recursive if ("types" in thing) checker in place.

[lukeed]

@SimenB I gotta run, but I put up a quick PR that should address your case/concerns. Tests attached that also encompasses your last snippet.

When unsafe is on, the only other option that has an interplay with it is conditions – so the idea is that by using unsafe you are directly passing in the list conditions you want to support. Only default is left on as a default condition – I think you agreed earlier that there was no logical reason to remove this.