Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for package.json exports #320

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

isaacs
Copy link

@isaacs isaacs commented Sep 26, 2023

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
Copy link
Member

ljharb commented Sep 26, 2023

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
Copy link
Author

isaacs commented Sep 26, 2023

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
Copy link
Member

ljharb commented Sep 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants