[Proposal] Support using any object satisfied Resolver type in import-x/resolver options

[GoodbyeNJN]

The resolver currently supports three reference methods:

• name -> eslint-import-resolver-name
• npm package name
• filesystem path

I propose that it support the direct use of any object satisfied Resolver type, and I further propose configuration other than this should be deprecated in the future.

Advantage:

• Reduce complexity when trying to require resolvers
• Defining a custom resolver is more convenient

For advantage 1, you can refer to ESLint’s thoughts on the introduction of flat config:

Use native loading for everything - one of our biggest regrets about eslintrc was recreating the Node.js require resolution in a custom way. This was a significant source of complexity and, in hindsight, unnecessary. Going forward, we wanted to leverage the loading capabilities of the JavaScript runtime directly.

Reference: https://eslint.org/blog/2022/08/new-config-system-part-2/#the-goals-of-flat-config

For advantage 2, there may be cases when existing resolvers don't meet the needs and needs to be temporarily added.

In this case, if the direct use of objects is supported, the steps of "creating new file -> processing filesystem path" can be eliminated, and the object can be created in place and used immediately.

In order to support the use of Resolver objects, the configuration structure of the import-x/resolver configuration item needs to be modified.

Before:

export type ImportResolver =
  | LiteralUnion<'node' | 'typescript' | 'webpack', string>
  | {
      node?: boolean | NodeResolverOptions
      typescript?: boolean | TsResolverOptions
      webpack?: WebpackResolverOptions
      [resolve: string]: unknown
    }

After:

export type Resolver = {
  interfaceVersion?: 1 | 2
  resolve: ResolverResolve
  resolveImport: ResolverResolveImport
}

export type ImportResolverItem = {
  // Just for identification, doesn't actually matter
  // node, typescript, webpack...
  name?: string

  // Enabled by default
  enable?: boolean

  // Options passed to the resolver
  options?: NodeResolverOptions | TsResolverOptions | WebpackResolverOptions | unknown

  // Any object satisfied Resolver type
  resolver: Resolver
};

export type ImportResolver =
  | LiteralUnion<'node' | 'typescript' | 'webpack', string>
  | {
      node?: boolean | NodeResolverOptions
      typescript?: boolean | TsResolverOptions
      webpack?: WebpackResolverOptions
      [resolve: string]: unknown
    }
  | ImportResolverItem[]

[GoodbyeNJN]

Sorry, I found out after opening the issue that there has been a discussion before: #40 (comment)

But I still want to emphasize that custom resolver should be supported. This does not conflict with the current logic of trying to require resolvers. On the contrary, it will bring certain conveniences.