rspack-resolver was breaking change

[pckilgore]

As of a recent version upgrade using rspack-resolver, the no-restricted-paths lint is breaks. Previously no native code was required to be run.

  1:1  error  Resolve error: Failed to load native binding
    at Object.<anonymous> (/Users/kilgore/gravity/monorepo/src/www/node_modules/rspack-resolver/index.js:368:11)
    at Module._compile (node:internal/modules/cjs/loader:1546:14)
    at Object..js (node:internal/modules/cjs/loader:1689:10)
    at Module.load (node:internal/modules/cjs/loader:1318:32)
    at Function._load (node:internal/modules/cjs/loader:1128:12)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
    at Module.require (node:internal/modules/cjs/loader:1340:12)
    at require (node:internal/modules/helpers:141:16)
    at Object.<anonymous> (/Users/kilgore/gravity/monorepo/src/www/node_modules/eslint-import-resolver-typescript/lib/index.cjs:6:22)  import/no-restricted-paths

[pckilgore]

Misread this dep as in the recent patch version, but I see now added in v4.

I suppose everything is about tradeoffs, but as a data point, the speed improvement here was minuscule (completely unnoticeable in a very very large codebase) but the new lack environment agnosticism is deeply annoying.

[JounQin]

What platform are you using? We'll target more platforms recently.

[JounQin]

Please help to try eslint-import-resolver-typescript@4.2.4 which adds new 4 targets support:

• i686-pc-windows-msvc
• armv7-unknown-linux-musleabihf
• powerpc64le-unknown-linux-gnu
• s390x-unknown-linux-gnu

[pckilgore]

Why should we need anything other than a javascript interpreter to run a javascript library? Not to mention the supply chain / security concerns shipping compiled binaries raises. Your lib. But poor choice, for very little gain IMO. Hope the community moves in a different direction. Sad v4 broke a good thing.

…

On Wed, Mar 26, 2025, at 12:47 AM, JounQin wrote: Please help to try ***@***.***` which adds new 4 targets support: • `i686-pc-windows-msvc` • `armv7-unknown-linux-musleabihf` • `powerpc64le-unknown-linux-gnu` • `s390x-unknown-linux-gnu` — Reply to this email directly, view it on GitHub <#405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQYQ4MMEM5QLCOIJDAIFD2WI5PHAVCNFSM6AAAAABZYVTIZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTGMYTAMRRG4>. You are receiving this because you modified the open/close state.Message ID: ***@***.***> JounQin*JounQin* left a comment (import-js/eslint-import-resolver-typescript#405) <#405 (comment)> Please help to try ***@***.***` which adds new 4 targets support: • `i686-pc-windows-msvc` • `armv7-unknown-linux-musleabihf` • `powerpc64le-unknown-linux-gnu` • `s390x-unknown-linux-gnu` — Reply to this email directly, view it on GitHub <#405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQYQ4MMEM5QLCOIJDAIFD2WI5PHAVCNFSM6AAAAABZYVTIZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTGMYTAMRRG4>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[JounQin]

It replaces slow enhanced-resolve, not a javascript interpreter, it's much faster.

Not to mention the supply chain / security concerns shipping compiled binaries raises.

It's open sourced at https://github.com/unrs/unrs-resolver

All releases are provenanced:

https://www.npmjs.com/package/unrs-resolver

[JounQin]

By the way, there are a lot of frontend toolchains built on top of rust/napi-rs nowdays.

• rspack
• oxc
• biome
• rolldown
• farm
• ...

And don't forget the new typescript-go.

[pckilgore]

Of course there's room for total replacement/revolutionary native tooling in the ecosystem. I love vite, for example. The problem is: this ain't that. This is some rust bolted onto an eslint helper that broke an eslint setup thats worked for nearly three years without an issue through two major ESLint versions. For no perceivable performance gain. And now I need to worry about the arch of the machines I'd put it on. No thanks! Call me when all of eslint is re-written into something with better perf. I don't find this discussion very productive by the way. Mostly here to report: 1. This broke our stuff, due to the native code dependency. 2. Won't be using it. 3. Leave a trail for other people who might be experiencing similar issues with previously-working code. Good luck!

…

On Wed, Mar 26, 2025, at 1:48 AM, JounQin wrote: By the way, there are a lot of frontend toolchains built on top of rust/napi-rs nowdays. • `rspack` • `oxc` • `biome` • `rolldown` • `farm` • ... — Reply to this email directly, view it on GitHub <#405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQYQ3WFIVPPUFYPJQA3R32WJEVDAVCNFSM6AAAAABZYVTIZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTGM4TMMBSHA>. You are receiving this because you modified the open/close state.Message ID: ***@***.***> JounQin*JounQin* left a comment (import-js/eslint-import-resolver-typescript#405) <#405 (comment)> By the way, there are a lot of frontend toolchains built on top of rust/napi-rs nowdays. • `rspack` • `oxc` • `biome` • `rolldown` • `farm` • ... — Reply to this email directly, view it on GitHub <#405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATQYQ3WFIVPPUFYPJQA3R32WJEVDAVCNFSM6AAAAABZYVTIZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJTGM4TMMBSHA>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[JounQin]

That's why it's a major v4 version?

For performance, are you using eslint-plugin-import or eslint-plugin-import-x?

The v3 resolver interface of https://github.com/un-ts/eslint-plugin-import-x would provide much better performance in case you didn't know.

// eslint.config.js, CommonJS is also supported
import { createTypeScriptImportResolver } from 'eslint-import-resolver-typescript'

export default [
  {
    settings: {
      'import-x/resolver-next': [
        createTypeScriptImportResolver({
          alwaysTryTypes: true, // always try to resolve types under `<root>@types` directory even it doesn't contain any source code, like `@types/unist`

          bun: true, // resolve Bun modules https://github.com/import-js/eslint-import-resolver-typescript#bun

          // Choose from one of the "project" configs below or omit to use <root>/tsconfig.json or <root>/jsconfig.json by default

          // use <root>/path/to/folder/tsconfig.json or <root>/path/to/folder/jsconfig.json
          project: 'path/to/folder',

          // Multiple tsconfigs/jsconfigs (Useful for monorepos, but discouraged in favor of `references` supported)

          // use a glob pattern
          project: 'packages/*/{ts,js}config.json',

          // use an array
          project: [
            'packages/module-a/tsconfig.json',
            'packages/module-b/jsconfig.json',
          ],

          // use an array of glob patterns
          project: [
            'packages/*/tsconfig.json',
            'other-packages/*/jsconfig.json',
          ],
        }),
      ],
    },
  },
]

There are also users feedback positive performance improve like #376 (comment)

I'd love to but can't help with your personally workspace for performance without reproduction.

[jgable]

I am also being affected by this rspack-resolver dependency issue out of nowhere. The error is extremely unhelpful, I'm glad that @pckilgore created this issue or I just would have thought some weird native binding issue was happening in my Github CI workflow.

That's why it's a major v4 version?

eslint-import-resolver-typescript/package.json

Lines 83 to 91 in a4a65dd

	"dependencies": {
	"@nolyfill/is-core-module": "1.0.39",
	"debug": "^4.4.0",
	"get-tsconfig": "^4.10.0",
	"is-bun-module": "^1.3.0",
	"rspack-resolver": "^1.1.0",
	"stable-hash": "^0.0.5",
	"tinyglobby": "^0.2.12"
	},

@JounQin This dependency change was published in 3.9.1, not a major v4 version. Since eslint-config-next specifies "eslint-import-resolver-typescript": "^3.5.2", we are encountering this issue. It's likely this is also affecting a bunch of other Next.js builds.

I was able to fix this by overriding the dependency in my package.json back to 3.5.2

"eslint-import-resolver-typescript": "3.5.2",

There is probably a later version that will also work but I haven't tried.

[JounQin]

@jgable Sorry for this first, but that doesn't mean to be a breaking change, we still support v3.x, would you like to raise a new issue with reproduction?

By the way, what's the unhelpful error exactly?

[jgable]

I will work on a repro today. This is happening on a Github action running on ubuntu-latest with Next 14 -> eslint-config-next.

The unhelpful error is Failed to load native binding in unrs-resolver.

I've tried specifying --os and --cpu but nothing is working and there are no directions to remedy so I've reverted.

[JounQin]

@jgable That seems a new target, please provide more arch/platform info.

[ckifer]

also facing this issue with the same error on Amazon Linux 2

Error is

Oops! Something went wrong! :(
ESLint: 9.16.0
Error: Failed to load native binding
Occurred while linting /local/p4clients/pkgbuild-const/workspace/src/<redacted>/test/client.test.ts:1
Rule: "import/namespace"
    at Object.<anonymous> (/local/p4clients/pkgbuild-const/workspace/src//<redacted>/node_modules/unrs-resolver/index.js:372:11)
    at Module._compile (node:internal/modules/cjs/loader:1469:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1548:10)
    at Module.load (node:internal/modules/cjs/loader:1288:32)
    at Module._load (node:internal/modules/cjs/loader:1104:12)
    at Module.require (node:internal/modules/cjs/loader:1311:19)
    at require (node:internal/modules/helpers:179:18)
    at Object.<anonymous> (/local/p4clients/pkgbuild-const/<redacted>/src/<redacted>/node_modules/eslint-import-resolver-typescript/lib/index.cjs:12:20)
    at Module._compile (node:internal/modules/cjs/loader:1469:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1548:10) 

[JounQin]

@ckifer Could be provide more useful info by debugging https://unpkg.com/unrs-resolver@1.5.0/index.js?

And in the meantime, you can use the wasi version for workaround by overrides(npm, pnpm) or resolutions(pnpm, yarn):

{
  "overrides": {
    "unrs-resolver": "npm:@unrs/resolver-binding-wasm32-wasi@latest"
  }
}

cc @jgable