Duplicate identifier 'GPUPipelineErrorReason' in latest TS nightly builds

[mjbvz]

Using the latest TypeScript nightly builds (tested with 6.0.0-dev.20251006), I see a few errors when using this library:

node_modules/@webgpu/types/dist/index.d.ts:342:6 - error TS2300: Duplicate identifier 'GPUPipelineErrorReason'.

342 type GPUPipelineErrorReason =
         ~~~~~~~~~~~~~~~~~~~~~~

  node_modules/typescript/lib/lib.dom.d.ts:40057:6
    40057 type GPUPipelineErrorReason = "internal" | "validation";
               ~~~~~~~~~~~~~~~~~~~~~~
    'GPUPipelineErrorReason' was also declared here.

node_modules/@webgpu/types/dist/index.d.ts:2767:13 - error TS2403: Subsequent variable declarations must have the same type.  Variable 'GPUError' must be of type '{ new (): GPUError; prototype: GPUError; }', but here has type '{ new (): never; prototype: GPUError; }'.

2767 declare var GPUError: {
                 ~~~~~~~~

  node_modules/typescript/lib/lib.dom.d.ts:12685:13
    12685 declare var GPUError: {
                      ~~~~~~~~
    'GPUError' was also declared here.

node_modules/typescript/lib/lib.dom.d.ts:40057:6 - error TS2300: Duplicate identifier 'GPUPipelineErrorReason'.

40057 type GPUPipelineErrorReason = "internal" | "validation";
           ~~~~~~~~~~~~~~~~~~~~~~

  node_modules/@webgpu/types/dist/index.d.ts:342:6
    342 type GPUPipelineErrorReason =
             ~~~~~~~~~~~~~~~~~~~~~~
    'GPUPipelineErrorReason' was also declared here.


Found 3 errors in 2 files.

I believe this I caused by a conflict with TypeScript's built-in dom library typings. Looks like GPUPipelineErrorReason and some other types may have been added to the built-in types, possibly with microsoft/TypeScript-DOM-lib-generator#2076

[kainino0x]

Seems they've started adding WebGPU to TypeScript core. Which makes sense because they said they would do so when Firefox or Safari shipped and now both have. (I can't find the issue where this was discussed, but it's on GitHub somewhere).

If they added the whole thing then the basic solution would be to simply not use @webgpu/types, but for some reason they've ended up with only a tiny subset of WebGPU. Commented on microsoft/TypeScript-DOM-lib-generator#2076 (comment)

Also, even in the long term, our types should be better than their autogenerated ones, so it would be nice if there's a way to use them instead. It doesn't look like there's a way to turn off the builtin ones piecemeal though.

[jakebailey]

Also, even in the long term, our types should be better than their autogenerated ones, so it would be nice if there's a way to use them instead. It doesn't look like there's a way to turn off the builtin ones piecemeal though.

In what way? The types in the DOM generator come from the spec...

[kainino0x]

Explained here:

types/README.md

Lines 106 to 111 in eb1d104

	The following differences will remain.
	- `onuncapturederror` strongly typed.
	- `addEventListener('uncapturederror')` type support.
	- `getContext` definitions.
	- `GPUExtent3DStrict` and `GPUOrigin2DStrict`.

though off the top of my head there's at least one other thing not mentioned there:

• type "branding" to create nominal typing of otherwise equivalent interfaces that aren't actually equivalent

and also aspirationally

• Consider two versions of types: one matching IDL exactly, and one that's stronger #47
• Use Array<T> | Iterable<T> ? #169
• Unergonomic type for size of GPUTextureDescriptor #147
• Make some/all input types readonly? (dict members, arrays, tuples) #29

however if it's not practical then I don't think it's a huge deal to tell people to stop using this project.

[jakebailey]

Ah. The generator project of course allows for manual tweaks to things the specs can't define. But it is odd that only a small amount of WebGPU made it in (but not entirely unheard of given the "two engine" rule)