Considering un-archive `eslint-import-resolver-oxc`

[SukkaW]

@9romise

It is very stupid to have multiple Rust-based resolvers that significantly bloat the size of node_modules. oxc-resolver is more widely adopted (@swc-node/register, vite, etc.) than unrs-resolver, so it is possible to re-use one package that helps reduce the final installation size.

I am willing to take over the maintenance of the package.

[9romise]

Make sense.

However, eslint-plugin-import-x now has unrs-resolver as a dependency, and we should probably deal with it first.

Anyway, thank you for bringing this up, and I invited you as a collaborator.

[SukkaW]

However, eslint-plugin-import-x now has unrs-resolver as a dependency, and we should probably deal with it first.

I am still thinking about this. Somehow, eslint-plugin-import-x needs to have a built-in resolver. Maybe I should not make it built-in in the first place, now I can't correct this error anymore.

[9romise]

In my opinion, eslint-plugin-import-x only needs to have a resolver written in Node.js that is compatible with resolver-next, and preferably without dependencies; at least, it shouldn't be native-based.

Perhaps what we can do now is to roll back createNodeResolver to be Node.js-based, or move unrs-resolver to optional peerDependencies, and alert users when they use it.

[SukkaW]

Perhaps what we can do now is to roll back createNodeResolver to be Node.js-based, or move unrs-resolver to optional peerDependencies, and alert users when they use it.

That's probably a good idea.

[JounQin]

LOL, that's totally fine to continue this project, while I want something to be clarified.

It is very stupid to have multiple Rust-based resolvers that significantly bloat the size of node_modules.

Sure, and if oxc-resolver passed all eslint-plugin-import-x and eslint-import-resolver-typescript test cases, I won't created unrs-resolver at all, as we talked previously.

And oxc-resolver doesn't support P'n'P well, that's why I chose to fork rspack-resolver instead of the original one. And I fixed a lot of edge cases, I believe you've already read: https://github.com/unrs/unrs-resolver#readme

The fact is, the resolvers can not be unified, each of them has different goals and target users.

oxc-resolver is more widely adopted (@swc-node/register, vite, etc.) than unrs-resolver, so it is possible to re-use one package that helps reduce the final installation size.

Sure it does, it's the original source of rspack-resolver and unrs-resolver, but it's not a dropping replacement for projects which requires more compatible targets like jest, I even fixed more issues when integrating with jest.

Perhaps what we can do now is to roll back createNodeResolver to be Node.js-based, or move unrs-resolver to optional peerDependencies, and alert users when they use it.

No thanks. We always need a built-in resolver to be used out of box which is eslint-import-resolver-node (resolve) previously, and then enhanced-resolve, and now unrs-resolver. Rolling back to Node.js-based resolver just means we change unrs-resolver back to maybe enhanced-resolve again, it's meaningless if your goal is to reduce the installation size.

So this will never going to happen to drop the built-in resolver.

Actually the users even requested to add eslint-import-resolver-typescript as a dependency of eslint-plugin-import-x: un-ts/eslint-plugin-import-x#150, so that everything will just work out of box.

So the fact is, unrs-resolver will still be a dependency of eslint-import-resolver-typescript and eslint-plugin-import-x, and using another resolver like eslint-import-resolver-oxc doesn't help to reduce the installation size at all.

By the way, https://github.com/kuoruan/eslint-import-resolver-next now is also powered by unrs-resolver.

[9romise]

For me, it's not just about installation size, but also ensuring consistent resolver behavior (which is why I treat oxc-resolver as a peer dependency).

No thanks. We always need a built-in resolver to be used out of box which is eslint-import-resolver-node (resolve)

However, as a user, needing to install a 2 MB+ dependency when I'm not using createNodeResolver does add a bit of overhead. But it's okay, I'm not the maintainer, and you're free to organize your package as you want.

So the fact is, unrs-resolver will still be a dependency of eslint-import-resolver-typescript and eslint-plugin-import-x, and using another resolver like eslint-import-resolver-oxc doesn't help to reduce the installation size at all.

It doesn't matter, I can easily remove unrs-resolver in my eslint-config preset.

By the way, kuoruan/eslint-import-resolver-next now is also powered by unrs-resolver.

Same as the first I say, I'd like to ensure the resolver behavior and don't consider using unrs-resolver for now cause the packages I'm using are generally dependent on oxc-resolver.

[JounQin]

Yes, I understand your position, and that's why I'm saying

that's totally fine to continue this project

Working out of box takes higher priority than installation size for most users, maybe 99.9%.

And as you said yourself, you can already remove unrs-resolver in your own eslint config, overrides with unrs-resolver: npm:oxc-resolver maybe?

[lishaduck]

I've been watching this issue for a while, but I missed the movement in import-x: un-ts/eslint-plugin-import-x#412. Can this be closed now?