Cannot find package error when using auto-install

[sigmaSd]

What version of Bun is running?

1.0.29

What platform is your computer?

linux

What steps can reproduce the bug?

import { Magika } from "magika@0.2.5";
const magika = new Magika();

What is the expected behavior?

no error

What do you see instead?

error

error: Cannot find package "long" from "/home/mrcool/.bun/install/cache/@tensorflow/tfjs@4.17.0/dist/tf.node.js"

Additional information

No response

[evgenyt1]

I've got similar issues with auto-install in 1.1.20.

For me

• windows:

  C:\Users\user1\projects>bun run index.js
  error: Unexpected while resolving package "cowsay" from "C:\Users\user1\projects\index.js"

• macos (arm):

  ➜  123 bun run index.js
  error: Cannot find package "cowsay" from "/Users/user1/tmp/123/index.js"

• linux works

No node_modules or package.json. index.js everywhere the same.:

import { say } from "cowsay";
console.log(say({ text: "grazing in the browser" }));

Just wondering if auto-install ever worked on macos? I’ve tried downgrading to a few older versions to check - doesn't work for me

UPDATE: It looks it has something to do with my system/user on macOS. Another user created on the same machine has auto-import working.

[notPlancha]

I'm having a similar issue as @evgenyt1 on windows, but having no problems on Ubuntu (using wsl).

Windows (powershell)

>mkdir temp
>cd temp
>echo 'import { say } from "cowsay"; console.log(say({ text: "grazing in the browser" }));' > temp.js
>bun run .\temp.js
error: Unexpected while resolving package "cowsay" from "C:\Users\Plancha\Desktop\temp\temp.js"

Bun v1.1.21 (Windows x64)

Linux (Ubuntu wsl)

>mkdir temp
>cd temp
>echo 'import { say } from "cowsay"; console.log(say({ text: "grazing in the browser" }));' > temp.js
>bun run temp.js
 ________________________
< grazing in the browser >
 ------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
>bun --version
1.1.21

This issue does look fundamentally different from @sigmaSd's, so maybe a new issue should be made