Fix TypeScript errors and enable tsc in CI

[digitalcora]

This adds type-checking to CI and resolves all existing type errors that are not due to implicit any types — in other words, all cases where the code or the type annotations are wrong in a way the compiler can prove without needing full type annotations. (This is more limited than it sounds; to catch all errors, explicit annotations are needed on most function arguments and return values, which is why noImplicitAny exists and is enabled by default in strict mode. For now, I've disabled it here, since we have such a huge number of implicit anys that it would explode the scope of this task.)

The "magic comment" @ts-expect-error suppresses any error that would be reported on the next line, and is used here to punt on situations that would be non-trivial to resolve, particularly in non-v2 code where we may never have to resolve them. Note this differs from @ts-ignore in that if there is no error on the next line, this is reported as an error — so if a future improvement to our types or the compiler results in the error being resolved, we'll know and can remove the comment.

There are a few general issues which are all fixed in similar ways:

• When the compiler can't prove the conditions of an if or switch cover all possibilities, and there is no fallback else or default, we have to add one. In most cases we can just throw an error, as we expect the code path to never be reached.

• Several places in existing type definitions were trying to use object as though it meant "object with unspecified fields of unspecified types". However, object actually means an "opaque" object: it only permits operations that would be allowed on any object, which does not include accessing any specific properties (which might not exist). The correct way to do this is Record<string, any>, though in some cases involving React props the best we can do without filling in a more detailed type is any.

• A type annotation is required on variables initialized to null or undefined and later assigned, or arrays initially declared as [] and later populated. The compiler does not backtrack to fill in the variable's type based on later usage; it only looks at the initial value.

• Similar to the above, useState requires a type parameter for the values that will later be assigned, if the type cannot be inferred from the initial value.

• Also similar to the above, useRef and forwardRef require a type parameter for the DOM element the ref will later be associated with. Due to a quirk of how the types are implemented for this function, null must also be explicitly provided as the initial value (we were already doing this in most places).

• The value in a ref is null during the initial render, so code that accesses properties of ref.current needs to account for this, even if we expect it to never happen (e.g. inside a useLayoutEffect).

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1207055911773551

[cmaddox5]

This is great! Thank you so much for this! Just one suggestion, otherwise good to go.

Also, Screenplay uses types pretty well at the moment, but this might be a good thing to add there as well. I can write up a task for that tomorrow.

[cmaddox5]

Well that's embarrassing. So this alert never worked because the variable didn't exist...

[digitalcora]

It seems to have been a copy-paste error? There is another alert like this in the same file where the variable does exist.

[github-actions]

Coverage of commit 4d1974c

Summary coverage rate:
  lines......: 44.4% (2839 of 6394 lines)
  functions..: 41.9% (1017 of 2427 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report