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

[OlivierZal]

Hi @JounQin, I'm not sure it's related to bun, but maybe to the new way alwaysTryTypes is defaulted in v4.

I didn't isolate the issue yet, but here's a project which you can test on by installing modules (with npm): https://github.com/OlivierZal/com.melcloud/blob/a3d4c53a5eadb8075397145f9e2c5b8aa7b957ee/eslint.config.js#L378

You can see that the modules are well resolved with alwaysTryTypes, but if you remove it from the config, modules are not resolved anymore (import/no-unresolved) while it should be – since v4 defaults it to true.

[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.

[JounQin]

You can see that the modules are well resolved with alwaysTryTypes, but if you remove it from the config, modules are not resolved anymore (import/no-unresolved) while it should be – since v4 defaults it to true.

@OlivierZal Thanks for reproduction, I'll take a look.

[JounQin]

@OlivierZal I cann't reproduce this, maybe you forget to run npm install after pulling?

If you continue face it, open a new issue with reproduction instead, thanks.

---

By the way, I'd recommend you to migrate to eslint-plugin-import-x for less dependencies and better performance with v3 resolver.

[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

[OlivierZal]

Thanks @JounQin, I confirm that the module has been updated. I'll migrate to what you suggest and file an new issue it persists.

[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

[OlivierZal]

[@OlivierZal](https://github.com/OlivierZal) I cann't reproduce this, maybe you forget to run `npm install` after pulling?

If you continue face it, open a new issue with reproduction instead, thanks.

By the way, I'd recommend you to migrate to eslint-plugin-import-x for less dependencies and better performance with v3 resolver.

@JounQin, update here for reported issue's record (since there's no need to file a new issue): I removed the whole typescript key, and that's what make resolution fail.