breaking changes from lib.d.ts being out of date with Strada

[controversial]

The following minimal program passes tsc but fails tsgo:

function doSomething(program: WebGLProgram) { void program; }

const gl = document.createElement('canvas').getContext('webgl2');
if (!gl) { throw new Error('WebGL2 context not available'); }

const program = gl.createProgram();
doSomething(program);

tsgo fails with

src/test.ts:7:13 - error TS2345: Argument of type 'WebGLProgram | null' is not assignable to parameter of type 'WebGLProgram'.
  Type 'null' is not assignable to type 'WebGLProgram'.

7 doSomething(program);
              ~~~~~~~

Found 1 error in src/test.ts:7

compiler options looks like the following:

    "target": "es2023",
    "lib": ["esnext", "dom", "dom.iterable"],
    "strict": true,

The failure appears to be because the return type for createProgram includes null in tsgo’s lib.dom.d.ts but not in typescript’s. tsgo might bundle old lib files which predate the changes in KhronosGroup/WebGL#3642 → microsoft/TypeScript-DOM-lib-generator#1753 → microsoft/TypeScript#60061 ?

This incompatiblity results in dozens of errors when I tried tsgo in a large project at work.

[jakebailey]

This is to be expected; our lib files come from a "random revision from last fall": https://github.com/microsoft/typescript-go/tree/main/_submodules

We're intending on bumping this, doing so will just mean we need to also start backporting all of the checker changes since then.

[controversial]

sounds good!

do more recent lib files depend on checker changes? or is it just that the lib files and the strada checker changes both come from the same submodule?

[jakebailey]

Mainly, bumping the submodule brings in all of the new tests from all of the changes since then, all of the message changes, new compiler options, etc.

[jakebailey]

Fixed by #1019; should be published within an hour.