Our TypeScript config is setup to check our code that will be bundled
and run in the browser. It shouldn't be running on esbuild plugins
that are run inside of node, and we never intended for it to.
Unfortunately, we mix our esbuild plugins into pkg/lib/ alongside
browser-based code, so it gets lumped in.
Add some excludes. Fortunately, we don't have to copy this to other
projects (like Cockpit Files) because they only check `src/*` in the
first place (and only include files in other directories if they are
explicitly imported).
Having `checkLib: false` in `tsconfig.conf` is a bad idea: it means that
if we want to check `.d.ts` files, we need a separate invocation of the
typescript compiler to do that. It also means that `.d.ts` files won't
be checked in your editor by default. Our workaround for this in
`test/static-code` only checks `cockpit.d.ts`, and we'll soon have other
declaration files.
We've been using `checkLib: false` as a crutch to avoid reporting errors
against `node_modules/`. The relevant TypeScript issue is still
unaddressed: https://github.com/microsoft/TypeScript/issues/30511
Modify `test/static-code` to only report errors if errors were found on
something outside of node_modules, but in that case, report all errors.
We do this with two invocations of `tsc`, to keep things simple, but
we'll only do the second invocation if we're reporting errors. To keep
things speedy, we turn on "incremental" mode (which writes a cache file
to speed things up). `.gitignore` that. It now takes only ~2s to do an
incremental check in the "no errors" case.
By default, `tsc` outputs a very nice format that shows the exact
content of errors, but this doesn't work by default in
`test/static-code` because we capture the output before displaying it.
Detect if we're running on a TTY (or if `FORCE_COLOR=1` as from our
workflows) and enable the "pretty" output in that case.
This is the base level of the language that the compiler targets (or
understands). We're about to add some code which uses `#private`
instance variables, which is a es2017 feature. We already depend on
es2020 library features, so let's allow the same for the core language.
This has a side-effect: setting `target: 'es2020'` changes the default
module resolution approach. Force it back to `"node"` so we can still
find our `node_modules`.
In Typescript when you say
interface iface {
prop?: string;
}
it means that the `iface` type can have an optional property `prop`
present, and if it is present it must be a string *or* `undefined`. The
reason for that is that given an instance `x` of type `iface`, if you
say `x.prop` then the result of that will be `undefined` if the property
is missing, so in some sense the ideas of "missing" and "`undefined`"
are semi-fungible.
This idea that a property can be present but defined to `undefined` is
incompatible with our definition of JsonObject, which doesn't permit
`undefined` to appear as a value in JSON documents, and has gotten us
into a lot of trouble in the past, trying to create types to describe
things that the bridge sends to us, in cases where a field may or may
not be present.
It seems like the Typescript people changed their mind about this. In
4.4 they introduced the "recommended" `--exactOptionalPropertyTypes`
flag which doesn't implicitly add `undefined` as a permitted value as a
side-effect of using `?`.
https://www.typescriptlang.org/tsconfig/#exactOptionalPropertyTypeshttps://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html#exact-optional-property-types---exactoptionalpropertytypes
This hasn't been made part of `--strict` yet because of how disruptive
it would be.
Let's switch this option on for our code and fix a couple of places
where it causes problems. One example is the `id` field of
`HelperTextItem`: it's optional, but if present, it must be a string.
Fix a bit of whitespace in tsconfig.json while we're at it.
Add the typescript compiler to our devel dependencies and run it from
`test/static-code`. We add an initial cockpit.d.ts and a tsconfig.json
which will get `tsc` to report errors against any `.ts` or `.tsx` files.
