Can you explain what `createNodeResolver` does?

[abrenneke]

Hi, your documentation suggests the following:

import { createTypeScriptImportResolver } from 'eslint-import-resolver-typescript'
import { createNodeResolver } from 'eslint-plugin-import-x'

export default [
  {
    settings: {
      'import-x/resolver-next': [
        createTypeScriptImportResolver(/* Your override options go here */),
        createNodeResolver(/* Your override options go here */),
      ],
    },
  },
]

What does createNodeResolver from this package accomplish that createTypeScriptImportResolver from eslint-import-resolver-typescript doesn't, exactly?

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Possible Duplicates

• [docs] Document next resolver and its usage examples in README #224

Related Issues

• Replacing the built-in default import resolver that supports exports and imports from package.json #208
• Some problem with the "restrictions" option #178
• feat: resolver-next should support single object resolver #320
• Upgrade to 4.8.0 (picomatch) breaks ts-paths import ordering #255

🔗 Related PRs

#272 - feat: map legacy node resolver to the new one with fallback support [merged]
#292 - docs: add more details about resolvers [merged]
#316 - docs: fix import-x/resolver-next description in readme [merged]
#321 - fix: accept non-array resolver in resolver-next setting [merged]

👤 Suggested Assignees

• SukkaW
• JounQin
• rakleed
• Perfectoff
• ChromeQ

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[SukkaW]

It is not about accomplishing more or less. It is about semantically mimicking runtime behavior.

createNodeResolver only implements the Node.js module resolving algorithm. If you do not use TypeScript, or do not have jsconfig.json or tsconfig.json in your project, you can just use createNodeResolver, which does not have the overhead of looking for tsconfig.json, computing TypeScript project references, looking up paths declared in tsconfig.json, etc.

As for why eslint-import-resolver-typescript has to be a separate package, yes, both eslint-plugin-import-x and eslint-import-resolver-typescript share the same Rust-powered resolver unrs-resolver, so it might make sense to have the TypeScript resolver built into the eslint-plugin-import-x. But in reality, it should not, as eslint-plugin-import does not use unrs-resolver (in fact, eslint-plugin-import doesn't even support exports in the package.json), and eslint-import-resolver-typescript exists to support both user bases.

[abrenneke]

I'm having trouble following your answer, sorry. I still don't understand why I'd want both, if I do use TypeScript?