Unable to resolve path to module 'bun:test' with 4.0.0 while 3.9.1 is OK

[tomchen]

Minimal repro:

git clone https://github.com/tomchen/eslint-import-resolver-typescript-bun-test.git

bun install

bun eslint

(or with npm, yarn, etc.)

It shows:

error Unable to resolve path to module 'bun:test' import/no-unresolved

But if you downgrade eslint-import-resolver-typescript v4.0.0 to v3.9.1, the error will disappear

P.S. @types/bun package is a shim that loads bun-types, type definitions for bun

[JounQin]

I do change the condition inside in v4, because I think we should not always check isBunModule for non-bun users.

And I'm not sure to understand this, process.versions.bun is unavailable when running bun eslint.

bun eslint 1.test.ts

logs:
process.versions.bun undefined [
  '/home/gitpod/.nvm/versions/node/v22.13.1/bin/node',
  '/workspace/eslint-import-resolver-typescript-bun-test/node_modules/.bin/eslint',
  '1.test.ts'
] // process.argv

Is this a bug of bun? @tomchen Can you report to them at the same time?

cc @Jarred-Sumner

[tomchen]

@JounQin the process.versions.bun issue does not seem to be relate to the issue I reported here - you can use my repro with npm, yarn and completely without bun, and the result is the same: v3.9.1 good, v4.0.0 bad

I suspect process.versions.bun being unavailable is because bun strictly respects the shebang line #!/usr/bin/env node in ./node_modules/eslint/bin/eslint.js and use node instead bun to execute eslint (or any other similar CLI js script with shebang line)

[JounQin]

the process.versions.bun issue does not seem to be relate to the issue I reported here - you can use my repro with npm, yarn and completely without bun, and the result is the same: v3.9.1 good, v4.0.0 bad

As I mentioned above:

I do change the condition inside in v4, because I think we should not always check isBunModule for non-bun users.

[tomchen]

For that process.versions.bun thing, indeed, https://bun.sh/docs/cli/bunx#shebangs. Even on Windows bun will use node although /usr/bin/env doesn't exist. If user wants to force using bun instead of node, they should run bunx --bun my-cli (or bun --bun eslint in our case). However I don't see changing #!/usr/bin/env node to #!/usr/bin/env bun works as stated in that bun doc page.

Anyway, not sure why there is bun checks in eslint-import-resolver-typescript, but process.versions.bun-based checks (used in eslint-import-resolver-typescript/lib/index.(c)js and by is-bun-module) within eslint will always return false without --bun flag

[JounQin]

Anyway, not sure why there is bun checks in eslint-import-resolver-typescript, but process.versions.bun-based checks (used in eslint-import-resolver-typescript/lib/index.(c)js and by is-bun-module) within eslint will always return false without --bun flag

Because the check for bun is a waste for non-bun users, I'll add a bun?: boolean option for this case then, still hope we can check whether the cli is executed by bun without userland flags.

cc @Jarred-Sumner

[JounQin]

@tomchen Please try with the new option: bun: true.

[tomchen]

Yeah, looks good, thx