New resolver design

[JounQin]

I haven't remove the resolver concept in eslint-plugin-import-x<=0.2 because I found that the webpack resolver may be still useful for those webpack users, and although we can use enhanced-resolve directly, but the settings can not fit all projects, I need to figure out how to set the resolver correctly for specific projects.

For example:

1. plain js
2. plain typescript
3. webpack specific syntaxes

I'm thinking the interface of import-x/resolver setting should be:

import type { ResolveOptions } from 'enhanced-resolve'

interface ResolverSettings {
  typescript?: boolean
  webpack?: boolean
  options?: ResolveOptions
}

By default, eslint-plugin-import-x should use enhanced-resolve directly to simulate native node resolve algorithm.

[silverwind]

Why not:

{
  resolver: "webpack",
  resolverOptions: {/* resolver-specific options */},
}

[SukkaW]

I don't like this idea of resolver: 'webpack' | 'typescript'.

Let's do resolver: require('@eslint-import/webpack') and resolver: import('@eslint-import/webpack').

[JounQin]

Let's do resolver: require('@eslint-import/webpack') and resolver: import('@eslint-import/webpack').

.eslintrc won't work is this case? Maybe you mean resolver: '@eslint-import/webpack' which is how eslint-plugin-import(-x) work currently?

I don't quite want to support custom resolver actually, that's why I proposed webpack?: boolean option, there should only a few resolvers for usage, ideally there should be no resolver concept except TypeScript, but webpack users may want to resolve webpack config automatically (I'm thinking if there are really eslint users using it nowadays because it does not work for webpack.cofig.ts/webpack.config.mjs, etc).

[SukkaW]

I don't quite want to support custom resolver actually, that's why I proposed webpack?: boolean option, there should only a few resolvers for usage, ideally there should be no resolver concept except TypeScript, but webpack users may want to resolve webpack config automatically (I'm thinking if there are really eslint users using it nowadays because it does not work for webpack.cofig.ts/webpack.config.mjs, etc).

Since we have multiple resolvers, and each one of them will have its own unique set of options. Perhaps we could approach it like this instead:

{
  webpack?: boolean | WebpackResolverOption | null
  typescript?: boolean | TypeScriptResolverOption | null
  node?: boolean | NodeResolverOption | null
}

[JounQin]

Since we have multiple resolvers, and each one of them will have its own unique set of options. Perhaps we could approach it like this instead:

That's how it's working nowadays except it requires specific npm packages installed. 🥹

But if we are going to adopt using enhanced-resolve instead, I think no node resolver should remain because it should be the default behavior. Should'd it?

For resolver options, could there be any other options except enhanced-resolve's?

I'm asking because I want to make a breaking change to drop support for previous resolvers instead of continuing.

[silverwind]

I don't like this idea of resolver: 'webpack' | 'typescript'.

Let's do resolver: require('@eslint-import/webpack') and resolver: import('@eslint-import/webpack').

That would work and be preferred in flat config format. Nonflat config has to support the package name as string.

[SukkaW]

For resolver options, could there be any other options except enhanced-resolve's?

Yeah, I want to do the same. There are many resolve libraries out there trying to mimic Node.js-like resolving algorithm:

• https://github.com/unjs/mlly
• https://www.npmjs.com/package/import-meta-resolve

[silverwind]

I think the only modern resolution mechanisms one needs are these two (names based on tsconfig moduleResolution):

• node-16: Node's resolution that requires file extensions. Likely should use import.meta.resolve and require.resolve, so should work without additional dependencies.
• bundler: Similar to node, but does not require file extensions, maybe this could cover the webpack case as well.

[SukkaW]

• node-16: Node's resolution that requires file extensions. Likely should use import.meta.resolve and require.resolve, so should work without additional dependencies.

We will still need a library as long as we are publishing ESM/CJS dual packages and want to have a unified behavior across eslint.config.mjs and eslint.config.cjs.

[silverwind]

Is CJS support still desired? CJS packages could just remain on using eslint-plugin-import.

Non-flat configs load as CJS but if I recall correctly, import.meta.resolve is also available there.

[SukkaW]

Non-flat configs load as CJS but if I recall correctly, import.meta.resolve is also available there.

Flat config supports both CJS and ESM, so there is no reason to make eslint-plugin-import-x a pure ESM module.

[silverwind]

Non-flat configs load as CJS but if I recall correctly, import.meta.resolve is also available there.

Flat config supports both CJS and ESM, so there is no reason to make eslint-plugin-import-x a pure ESM module.

Ah, you are right. I wasn't aware that it's possible to support CJS in flat config as I head read this, so transpilation to CJS will be required if non-flat config is to be supported.

[SukkaW]

@JounQin Was reading this blog post: How we made Vite 4.3 faaaaster 🚀, and here I quote:

Vite 4.2 heavily depends on the resolve package to resolve the dependency's package.json, when we looked into the source code of resolve, there was much useless logic while resolving package.json. Vite 4.3 abandons resolve and follows the simpler resolve logic: directly checks whether package.json exists in the nested parents' directories.

IMHO should we build our own resolving algorithm as well?

[ehoogeveen-medweb]

Regarding typescript, it would be great if this could somehow piggyback off of typescript's own module resolution.

https://github.com/import-js/eslint-import-resolver-typescript mostly matches typescript, but I don't think it supports the project service, so you still have to tell it about all the relevant projects manually (in dependency order).

typescript-eslint does support the project service through EXPERIMENTAL_useProjectService and they intend to stabilize it as projectService for the next major release: typescript-eslint/typescript-eslint#9084