Roadmap to deprecate and archive this resolver

[JounQin]

Previous discussion: #80 (comment)

Would #40 and import-js/eslint-import-resolver-typescript#445 be a blocker for you or not?

cc @9romise @SukkaW

[9romise]

I'm not sure either.
If anyone uses it, I'm certainly happy to continue maintaining this repo. But I would still recommend people to use eslint-import-resolver-typescript.
To me, the most useful might be alias, but it can also be parsed in tsconfig, so this feature isn't really that important.

[JounQin]

alias seems only useful for a pure js project, any ts projects should alreay have tsconfig.json files, right? And plugins like https://github.com/aleclarson/vite-tsconfig-paths even depends on tsconfig.json files.

So actually I'm a bit unsure what's the use case of bundlerConfig, are you using it yourself?

[9romise]

Actually, I always use TypeScript.
But I'm following auto-detection, which might make my resolver config more consistent with the bundler config, but in fact, they're not too much of a problem.
The original idea for this feature was when I saw the demand for it from JS users in the community.

[JounQin]

But I'm following auto-detection, which might make my resolver config more consistent with the bundler config, but in fact, they're not too much of a problem.

As I mentioned above, if you're using vite-tsconfig-paths or similar tools, there should be no differences between the resolver vs the bundler.

The original idea for this feature was when I saw the demand for it from JS users in the community.

Any references?

[9romise]

As I mentioned above, if you're using vite-tsconfig-paths or similar tools, there should be no differences between the resolver vs the bundler.

For alias, yes, but there are some configurations such as extensions, mainFiles, and so on. These configurations are also synchronized by bundlerConfig, but they are not important for eslint-import-resolver.

Any references?

Sorry, I didn't leave a record, and I can't find a reference now. But I'm sure there's not much of a need.

[JounQin]

For alias, yes, but there are some configurations such as extensions, mainFields, and so on. These configurations are also synchronized by bundlerConfig, but they are not important for eslint-import-resolver.

What do you mean with "but they are not important for eslint-import-resolver"?

https://github.com/un-ts/eslint-plugin-import-x/blob/f193e733824e395ecb254cba23fe40d2fbc61348/src/node-resolver.ts The built-in node resolver of import-x and import-resolver-typepscript both support custom those options.

Sorry, I didn't leave a record, and I can't find a reference now. But I'm sure there's not much of a need.

Then my proposal would be:

1. deprecate this resolver on npm and recommends import-resolver-typescript in the deprecation message and ask for feedbacks
2. don't archive this repo quickly, let's get/wait feedbacks for maybe 6 months
3. let's see how strong the bundler config resolving feature is requested to decide should we port it into import-resolver-typescript or plugin-import-x
4. archive this repo

[9romise]

What do you mean with "but they are not important for eslint-import-resolver"?

un-ts/eslint-plugin-import-x@f193e73/src/node-resolver.ts The built-in node resolver of import-x and import-resolver-typepscript both support custom those options.

I don't think users will pay attention to options other than alias. If these options have issues, they would likely be quickly exposed by the bundler. Automatically syncing them in eslint-import-resolver may not be in high demand.

[JounQin]

I don't think users will pay attention to options other than alias.

Maybe true, and that's why I'm proposing to deprecate this npm package to collect feedbacks (npm deprecate command can be undo at anytime).

That's said, I believe there could be a usage case, for example, importing assets? Not for sure, I'm sleepy.