TS Type Resolution Issue with Nested @types Packages Using `bun install`

[robobun]

👋 Hi everyone,

I'm encountering an issue with TypeScript type resolution when using bun install as opposed to npm install. Specifically, the problem is with the @types/videojs-mobile-ui package which augments an interface provided in @types/video.js

When I use npm install, everything works fine. However, when I use bun install, it installs a nested copy of @types/video.js inside @types/videojs-mobile-ui, which seems to cause type resolution conflicts.

Here's what the directory structure looks like with npm install:

node_modules/@types/videojs-mobile-ui/
├── LICENSE
├── README.md
├── index.d.ts
└── package.json

And here it is with bun install:

node_modules/@types/videojs-mobile-ui/
├── LICENSE
├── README.md
├── index.d.ts
├── node_modules
│   └── @types
│       └── video.js
│           ├── LICENSE
│           ├── README.md
│           ├── index.d.ts
│           └── package.json
└── package.json

Manually removing the nested @types/video.js resolves the issue, but I'd like to understand why this is happening and how to prevent it in the future. I couldn't find a dedupe option in the Bun documentation.

Any insights would be greatly appreciated!

Originally reported on Discord: TS Type Resolution Issue with Nested @types Packages Usingbun install``

[vinnichase]

Facing the same issue with bun add sst. But it is not consistent across projects even though the exact same version sst is installed in both projects. In one project it copies nested node_modules with 3 subfolders with resulting correct type resolution. In another project it copies 7 subfolders in nested node_modules including a /constructs folder with type declarations that are incorrectly resolved in the project causing a type error.

Current workaround is for me to manually delete the constructs folder. Removing and adding sst brings the folder back (in the correct project it does not bring the folder) however bun install does not override the sst folder, so for me its a viable solution now.

In general it is very frustrating to know that bun might not install a deterministic folder for a given package version.

[vinnichase]

OK updating bun to 1.0.13 seems to fix my particular problem... OP can you confirm that also solves your issue. Then this could be closed.

EDIT: OK that was again flaky. Getting the exact same problem in another project. I had to switch to pnpm again.