<reference no-default-lib="true" /> in bun-types causes vscode to not recognize lib.dom.d.ts types

[o-az]

when I add bun-types to tsconfig.json vscode is unable to recognize types from lib.dom.d.ts (FormData, navigator, etc.).

Removing bun-types from tsconfig.json brings back DOM types but I want but types so I tinkered around. I commented out this line specifically in bun-types and it seems to have solved the problem. Now I can have bun-types in tsconfig.json and I'm getting DOM types.

https://github.com/Jarred-Sumner/bun/blob/ee83e25120f8ff52fb44d83ac25b965c2cc2b062/packages/bun-types/types.d.ts#L5

[Electroid]

@colinhacks Thoughts on how we can make this better?

[rauchp]

Tested today and it appears this is still happening. This is pretty similar to the problem cross-fetch had, right?

[loicnestler]

Any updates on this?

[dan-lee]

Can we not remove the triple-slash directive and set noLib to true in the tsconfig.json?

Source: https://stackoverflow.com/a/31696608/612202 & https://basarat.gitbook.io/typescript/type-system/lib.d.ts#lib.d.ts

[lukasver]

Experiencing same issue with navigator and dom API

[iam-medvedev]

I fixed this by creating a types.d.ts file with the following line:

/// <reference lib="dom" />

tsconfig.json:

{
  "compilerOptions": {
    "types": ["bun-types", "./types.d.ts"]
  }
}

[lukasver]

I fixed this by creating a types.d.ts file with the following line:

/// <reference lib="dom" />

tsconfig.json:

{
  "compilerOptions": {
    "types": ["bun-types", "./types.d.ts"]
  }
}

worked like a charm! thank you! 👍

[TkDodo]

faced this as well today. we have no types declared, and as soon as I add:

{
  "compilerOptions": {
    "types": ["bun-types"]
  }
}

we're losing the dom types everywhere. The workaround from @iam-medvedev works, but we're in a monorepo so I'd need to do this in every package :/

[lgarron]

In trying to adopt bun test for a moderately large project, I also ran into this.

@iam-medvedev's workaround worked, but bun-types conflicts with @types/node as well, and we can't avoid @types/node as a transitive dependency due to #4751 (that is, we need to keep around another test runner because bun can't run Playwright yet). Leaving @types/node out of compilerOptions.types sort of works, but tsc still fails type checking due to the conflict.

It would be nice to have a version of bun-types that only declares exports, but doesn't modify or conflict with any other declarations. Then you could still import from e.g. bun:test without any effect on the rest of the project.

[samvv]

I just encountered this issue and I'm a bit shocked that it hasn't been solved yet. I'm not expecting any package I install to override my lib configuration in tsconfig.json and break my project. Tracking down this bug also took quite some time. The suggestion by @dan-lee seems to me like the way to go.

[iansinnott]

In trying to adopt bun test for a moderately large project, I also ran into this.

Indeed. I was also looking to incrementally adopt bun, starting with the test framework. However, this issue adds a lot of friction.

bun test has a really nice adoption story out of the box (with the exception of this issue):

1. Create a something.test.ts file anywhere in the project
2. Write tests using import { expect, test } from "bun:test";
3. Run bun test

Very fast and easy to set up, except for getting the types to work.

Fixing this issue would help bun get a foothold in existing codebases.

[JosephClay]

Worth noting that this issue is extremely difficult to identify in a large codebase, as TS doesn't point to bun-types as being the problem (the types just stop working)

[lgarron]

I'd like to highlight that this becomes increasingly more important as bun gains importable functionality:

I was super excited to try out https://bun.sh/blog/the-bun-shell#introducing-the-bun-shell , but it's impractical to use in our project because we can't import bun-types due to the issues described in this thread. But we can't really have project-critical scripts that are failing to type-check either.

At this point, I'd settle for a consistent way to vendor most of bun-types in a way that doesn't strip compatibility with TypeScript's default types (and @types/node), but I'd really appreciate first-class support for using bun types without conflict.