add support for package.json exports

[isaacs]

Work in progress, but a spike to start going in that direction.

TODO:

• there's a bunch of lint failures, but most of them look like they're not coming from the new code
• needs tests
• pretty sure it's not matching the error wording that node uses, it seems like some care has been taken to match, so it'd be good if this did as well, I'm guessing?

[ljharb]

This doesn't seem to handle restricting the conditions node supports; it also doesn't include support for every permutation of "exports" support node has shipped, which is part of the delay here.

What about wildcard exports, or directory subpath imports?

[isaacs]

Yeah, it's just a spike, copied some code out of another program to get it started.

This doesn't seem to handle restricting the conditions node supports;
What about wildcard exports, or directory subpath imports?

resolve-import actually supports all of that today, and has error messages that match node's (though I believe they are changing a few in 20.8 to be more sensible, so that might not be 100% true for long; I plan to match node 20.8 when they land). The main thing it's lacking is sync support, but that wouldn't be too hard to add, and I have a few cases where it'd be nice to not have to await it.

it also doesn't include support for every permutation of "exports" support node has shipped, which is part of the delay here.

When you say "every permutation", do you mean having modes to only support what node 12 could do, only what node 14 could do, and so on? resolve-import matches node.latest, which is a strict superset of all those permutations.

The other likely blocker is that there's no way resolve-import is going to be made to support node <14. It uses const, let, async/await, and so on.

I think this is a decision point for browserify/resolve, is it more important to maintain support for historical node versions, or make a semver major break and add support for node versions that handle package.json "exports"? The maintenance cost of permanent backwards compatibility will only increase; the cost today is a lack of current compatibility.

[ljharb]

Yes, I do mean that; and no, it's not a strict superset of all permutations.

Indeed, not supporting node < 14 is a blocker. I'll eventually get to this work myself if needed, and it's eternally far more important to me to retain backwards compatibility than to get an implementation faster.

Also, see #224.