Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: old
import-x/resolve
options now use new built-in node resolver #272New 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
base: master
Are you sure you want to change the base?
feat: old
import-x/resolve
options now use new built-in node resolver #272Changes from all commits
85a9702
89e3937
2a66b0a
ffcc7d3
161c7cc
28189c5
2b0fce1
05fcf87
d21b8d8
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems not covering
import-x/resolver#node
,import-resolver#eslint-import-resolver-node
and ,import-x/resolver#<absolute-path-of-resolver-node>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to leave those three in the major version bump. These could potentially be a breaking change (unlike
import-x/resolve
, which almost nobody uses, but we can run tests on it).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO, they can still use
eslint-import-resolver-node
explicitly, we should not stop it.It is the
import-x/resolve
that is default toeslint-import-resolver-node
and we need to replace that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolver-node
is the default resolver and doesn't supportexports
, that's makes a lot of duplicate issues reported in upstream, as I mentioned above, if no specific features used byresolver-node
options, we can safely use our new node resolver instead, otherwise we can just fallback to originalresolver-node
when unsupported options passed.Then no breaking changes, and no regressions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only default thing that happened here is in the
import-x/resolve
(withoutr
); my PR is trying to remove it. There is nothing else that defaults toresolver-node
.Here is the thing, it is possible to have both node resolvers enabled:
Then it just becomes "why my
exports
are not working? I have already updated to the latest version! You are lying in the CHANGELOG!". Or "exports
only works times to times!"Let's just not overcomplicate things. If they explicitly declare
node
in theimport-x/resolver
(soon to becomeimport-x/resolver-legacy
), then we useresolver-node
. Only if nothing is explicitly defined then we use our built-in node resolver by default.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing
resolver-node
from dep already breaks the related users.We can warn and document if unsupported options passed, it'll fallback to original
resolver-node
.I think
resolver-node
should be an optional peer.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmm. You are right. Let's move this to the breaking change then, and no legacy options will be supported. Closing now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still want to support it with my proposal, so I'll continue your work to finish it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
paths
should only be applied whenmoduleDirectory
fails to resolve (found: false
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well. Probably just implements this in
unrs-resolver
TBH.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could be confusing between
modules
vspaths
, and I think that's why this is not implemented inenhanced-resolve
.paths
is also discouraged byresolve
itself: