fix #2388: suppress type errors if lib.dom not enabled

[sibbng]

Closes #2388 Supersedes #3679

Deno's VS Code extension pulls the URL type from the esbuild package, even with lib.dom enabled. This issue does not appear with VS Code's built-in TypeScript extension, but I can still see the definitions when I peek at type definitions, and it's confusing to see esbuild there.

To fix this, I added // @ts-ignore before the properties and removed global WebAssembly and URL types. This ensures that if lib.dom is available, the properties will have the correct types; otherwise, they default to any, avoiding type errors like in #2388.

/cc @remcohaszing

[remcohaszing]

There seems to be some misconception on how this works.

Deno's VS Code extension pulls the URL type from the esbuild package, even with lib.dom enabled. This issue does not appear with VS Code's built-in TypeScript extension, but I can still see the definitions when I peek at type definitions, and it's confusing to see esbuild there.

Global interfaces and namespaces are declaration merged. The global type URL defined by lib.dom has a set of properties hostname, pathname, etc. The global type URL defined by esbuild has an empty set of properties. The global type URL has all properties from lib.dom as well as all properties from esbuild. Neither overrides the other.

If Deno's VS Code extension does this differently, that would be a bug in Deno's VS Code extension. However, more likely is that you forgot to include Deno’s type definitions and have skipLibCheck enabled. Because you didn’t include Deno’s type definitions, nor the DOM types, the type of req.url had a type error, referencing non-existent global type URL. Because you have skipLibCheck enabled, this error is suppressed, and the type of req.url is any.

Now by upgrading to a new version of esbuild, this error in your setup has surfaced.

To fix this, I added // @ts-ignore before the properties and removed global WebAssembly and URL types. This ensures that if lib.dom is available, the properties will have the correct types; otherwise, they default to any, avoiding type errors like in #2388.

@ts-ignore comments are removed when compiling TypeScript. You can use @ts-ignore comments if you manually author declaration files, but even then it should be a last resort.

[sibbng]

Thanks for great explanation. It's definitely a bug in Deno's VS Code extension.

When I use Peek > Peek Type Definition command with built-in extension I can see lib.dom.d.ts, @types/node and esbuild/main.d.ts there, but for some reason when I enable Deno VS Code extension I only see esbuild/main.d.ts.

However, more likely is that you forgot to include Deno’s type definitions and have skipLibCheck enabled

I definitely enabled them in my deno.json file.

  "compilerOptions": {
    "lib": ["dom", "deno.ns"]
  },

I will raise an issue on Deno VS Code repo as soon as I get a minimal reproduction.