refactor: unify TypeScript project

[turadg]

Description

I was trying to create a type coverage report and along the way it was easiest to unify the type checking into one TypeScript project. With this the checker can be more comprehensive and it turns out there are over a thousand type errors that were masked by the earlier config.

EDIT: having a single TypeScript project will solve OOM in eslint https://github.com/typescript-eslint/typescript-eslint/issues/1192#issuecomment-1153418862

Security Considerations

Documentation Considerations

Testing Considerations

[dckc]

Is typechecking still included in yarn lint after this PR? If not, note that much more loudly in the description, please. It would be a breaking change w.r.t. my mental model.

[mhofman]

What is the advantage to moving the jsconfig.json to the root? Could the same be accomplished by having a base definition at the root and having each project extend it? My main concern is in the future being able to gradually move some packages to stricter rules.

[turadg]

Is typechecking still included in yarn lint after this PR? If not, note that much more loudly in the description, please. It would be a breaking change w.r.t. my mental model.

I've split that out to #4416

What is the advantage to moving the jsconfig.json to the root?

One is that we can now do yarn tsc at the root. I think there are other performance advantages for IDEs to check over one project instead of one per package.

Could the same be accomplished by having a base definition at the root and having each project extend it? My main concern is in the future being able to gradually move some packages to stricter rules.

I think there can still be overrides in sub-directories. I share the desire to have some packages go stricter sooner.

microsoft/TypeScript#28306 talks about this and here's an example of making nested configs work: microsoft/TypeScript#28306 (comment)

Though we might be better off on a per-file than per-package basis:
https://www.npmjs.com/package/typescript-strict-plugin?activeTab=readme

[mhofman]

One is that we can now do yarn tsc at the root. I think there are other performance advantages for IDEs to check over one project instead of one per package.

yarn workspace should be able to handle running a single command at the root, right?

I'm also a little concerned this might hide some ambient style issues, were a package on its own might not be valid, but taken in combination with other packages would be fine.

I think there can still be overrides in sub-directories.

If the sub directory configs are automatically picked up and create a scope, that might be sufficient.

I think I still don't quite understand the motivation. I'd like to be able to run yarn lint:types or equivalent in a package and get a type check scoped to that package. In my mind that looks like a base jsconfig with the default compiler options in the root, and explicit jsconfig in every package with compiler options override (potentially none), and per package include / exclude as not all packages may have the same shape.

[turadg]

Noting this other motivation: to support refactoring. If we had a root project that others inherit from I think @warner wouldn't have run into the problem with jsconfig missing some files. I'm not sure but I suspect that VS Code will also be challenged by refactorings across packages since it sees each package as independent.

[mhofman]

How would type checking a single package work with a root config? This is actually something I'm slightly frustrated at with the prettier change, that I cannot check the formatting when in packages/foo. Less of an issue for prettier since that's fast enough on the whole project, but it bugs me I need to keep doing cd or keep 2 terminals open.

[turadg]

How would type checking a single package work with a root config?

Each package config inherits the root config but still defines its own. So I don't think it would change the yarn lint:types ergonomics we have now.

This is actually something I'm slightly frustrated at with the prettier change, that I cannot check the formatting when in packages/foo. Less of an issue for prettier since that's fast enough on the whole project, but it bugs me I need to keep doing cd or keep 2 terminals open.

I had assumed that only CI would want to check Prettier and people would want to fix Prettier (since it's automatic and safe). If it's worth having a per-package check for it we can add that back. Personally I just have my IDE format to pretty on save.

[dckc]

I see discussion of some pretty fine details about sqlite among kernel devs. @gibson042 are you confident that this upgrade is OK? Or should it get review by others?

[gibson042]

The major version bump was just to drop Node.js 16, so I'd be surprised if this affects anything not covered by unit tests. @warner gets deeper on this than I do, though.

[turadg]

runtime change so pulled out to #8590