Change Request: replace `enhanced-resolve` with `unrs-resolver` which is used by other `import-resolver`s

[JounQin]

eslint-plugin-n version

v17.18.0

What problem do you want to solve?

https://github.com/unrs/unrs-resolver#readme is a @nap-rs project which is much faster

What do you think is the correct solution?

Just replace enhanced-resolve with unrs-resolver which is alreay adopted by https://github.com/un-ts/eslint-plugin-import-x, https://github.com/import-js/eslint-import-resolver-typescript, https://github.com/kuoruan/eslint-import-resolver-next, etc.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

cc @aladdin-add @ota-meshi

[jeremy-code]

+1, currently if package.json import path, it will error with Can't resolve 'package-name/path-to-file.js' in '...' eslint n/no-missing-import

[JounQin]

FYI, unrs-resolver has just been adopted into Jest 30: https://jestjs.io/blog#performance--memory-improvements

[aladdin-add]

@JounQin It would be helpful if you could provide us with some perf comparison data(compared with using enhanced-resolve).

If its performance improvements help the users, I'm all for it. @scagood @voxpelli wdyt?

[voxpelli]

Quoting a discussion from another project:

Just like we require reproductions for bug reports we should require similar "reproduction" for the claims in refactorings / improvements.

They should prove:

• Demonstrated and impactful real world improvements that proves meaningful in real world use cases
• Meaningful and thorough evaluation / research into unintended side effects and regressions
• Exhaustive comparison with other alternatives that proves this is the winning approach

On top of that they should disclose eg:

• Personal affiliation with the proposed alternatives
• Personal motivation for wanting the change

I note the authors failure to disclose their affiliation with the modules mentioned in their post (the author is a maintainer / co-maintainer of many of them, including the module they want us to switch to). I conclude eg. neostandard/neostandard#285, unrs/unrs-resolver#88, unrs/unrs-resolver#92 (review). Lastly I note their handling of eslint-config-standard over in renovatebot/renovate#36018 / es-tooling/module-replacements#209 (including the trademark issue at standard/eslint-config-standard#351 (comment)).

I think the quoted requirements makes sense in the context of this kind of requests.

Due to events in the recent past I do not want to delve into this or pass any kind of judgement on this though.

[JounQin]

I think the quoted requirements makes sense in the context of this kind of requests.

Due to events in the recent past I do not want to delve into this or pass any kind of judgement on this though.

I don't know what you're trying to approve here.

All my codes are open sourced, did you mean I should mention that unrs-resolver is my own project? I forked projects when the original one can not meet my own requirements, I don't know what's the problem here, LOL. And rejections like you linked are totally fine to me. I don't get which point to get you upset here, but clearly you think my @eslinter/eslint-config-standard is a mistake, and I hope so actually, if eslint-config-standard is maintained well.

And at eslinter/eslint-config-standard#11 (comment), I got a promise that

so the standard packages will soon see a new release.

Then that would be the utmost significance of @eslinter/eslint-config-standard: pusing eslint-config-standard to be maintained again.

[JounQin]

@aladdin-add

It would be helpful if you could provide us with some perf comparison data(compared with using enhanced-resolve).

I think a prepared PR would help?

[aladdin-add]

yes, please feel free! :)