repo: upgrade to TypeScript 4

[paul-marechal]

@tsmaeder I remember saying we should avoid upgrading TypeScript, but I changed my mind.

I want to upgrade in order to build slightly faster and hope to fix an issue with our current version of tsserver being quite slow on our repo. Switching to TypeScript 4.4 I couldn't notice the lag anymore.

Upgrading the TS version we use to build this repo might lead to breakage in downstream applications in the following case:

• We start using a new TypeScript 4 construct. e.g. Named tuple elements (type SomeTuple = [a: string, b: number])
• Downstream consumers of Theia use TypeScript 3 and it fails to parse this definition.

The solution would be for them to also upgrade their version of TypeScript in such a case. I think this is manageable.

As @msujew mentioned: TypeScript doesn't follow semantic versioning. But patch versions shouldn't bring breaking changes.

Closes #10354.

How to test

• Building this repo should still work.
• Once everything is built, try running a few LS commands and get a feel for the performance. It shouldn't take to long to complete. It's quite subjective...

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[msujew]

The localization-manager package also has a dependency to typescript (as a runtime dependency), do you mind updating that one as well? I think we should keep them synchronized.

[tsmaeder]

@paul-marechal I'm not against keeping up with typescript versions, but I'm getting a bit worried with the rate of changes we have in our build system. We don't want adopters to have to catch up every release. Would it be possible to update the tooling (which is what we want) and keep the syntax checking at 3.9?
It would be nice if we could be more predictable with such changes, such as announcing breaking updates to tooling a release in advance.

[paul-marechal]

We don't want adopters to have to catch up every release.

The build system shouldn't impact adopters that are consuming the npm packages we are publishing, like at all?

Beside the potentially new type definition, which won't cause any issue until the moment someone makes a PR using new things from TypeScript.

For those that build the repo themselves, doing yarn alone should do everything up until the point where all packages are built and ready for use. Unless the wiring is deeply plugged into how Theia is built?

[paul-marechal]

and keep the syntax checking at 3.9?

Not AFAIK, we'd have to keep an eye out on what goes in but that doesn't sound super robust.

[tsmaeder]

The build system shouldn't impact adopters that are consuming the npm packages we are publishing, like at all?

Since we have no way to ensure that no > 4.0 constructs are used in Theia, they will effectively have to move to 4.0, as well eventually. Looking at the Typescript changelog, that might be a breaking change.

[paul-marechal]

@tsmaeder Yes, indeed. Although it should be a trivial change for downstream clients, should anything break.

Last time we broke something related to TypeScript it was the compilation target and the community seem to have received it well? With the Node/Electron upgrade we might be able to bump it again btw.

Also, the TypeScript version we've been using is a year old already. I don't think it's a crazy idea to try and not lag too much behind in the future. I think Anton had suggested targeting latest for the TypeScript version and with our yarn upgrade process I was worried we would have issues. With hindsight it would actually be fine and we should fix any new compilation error as part of the upgrade process, unless it's a big breakage (unlikely).

In other projects this dependency upkeep and build system care is usually called "chore" because it is, but it's necessary for a healthy project IMO. I had the pleasure of addressing parts of the build system that hadn't changed in a year or more, and the debt was painful to pay in full. Doing it incrementally should be better.

[colin-grant-work]

Looks fine to me. Minor comments on the @ts-expect-error comments. Probably if we compiled Phosphor ourselves with a later TS version, we could get rid of those, but that doesn't seem worth it. I don't love the number of new any's that are introduced, but they point to places where we're not being as clear about our intent as we should be, and I'm fine with them for now.

The upgrade didn't seem to improve my build or code browsing experience, but I agree with @paul-marechal that these are chores that we're stuck with - we can't really plan to lag behind indefinitely, so we'll have to do this at some point. Certainly open to discussion about the schedule on which we should upgrade our tools, but this doesn't seem hasty to me.

[msujew]

By the way, I can confirm that running Find All References with TypeScript 4.4.4 runs way faster in Theia now, compared to 3.9. However, the current default for the TypeScript extension seems to be 3.8, so I had to manually change it to the workspace version to verify this.

[paul-marechal]

the current default for the TypeScript extension seems to be 3.8

How? I thought the extension would use what VS Code bundles I thought it would be using 4.4?

We also have the TypeScript version set to node_modules/typescript/lib in our .vscode/settings.json file, so it should pick up the locally installed one?

[msujew]

How? I thought the extension would use what VS Code bundles I thought it would be using 4.4?

@paul-marechal I was confused as well, but we currently use the 1.45.1 version of the typescript-language-features extension in the Theia repo, which comes bundled with TypeScript 3.8.3:

And you're right as well that we added the appropriate setting to use the node_modules/typescript/lib library, but there's a huge catch hidden in the docs of the extension:

The typescript.tsdk workspace setting only tells VS Code that a workspace version of TypeScript exists. To actually start using the workspace version for IntelliSense, you must run the TypeScript: Select TypeScript Version command and select the workspace version.

So the setting only tells the extension which workspace version should be used, but it doesn't tell it to use that one from the start. The user has switch manually. I just learned about that one as well.

[paul-marechal]

Thanks for pointing all of this out @msujew.

VS Code will automatically detect workspace versions of TypeScript that are installed under node_modules in the root of your workspace.

This means that the typescript.tsdk setting we had is useless now, so I removed it.

edit: Turns out we can't really delete it.

[paul-marechal]

I rebased this PR on master and also pushed TypeScript to 4.5.

[JonasHelming]

@tsmaeder

[msujew]

Thanks Paul! Looks good to me, I have a small remark, but I'll approve this already 👍

[vince-fugnitto]

The changes look good to me 👍
I confirmed that

• editing in vscode still shows markers for tslint
• typescript functionality works (and feels quicker)
• the application builds and starts

[colin-grant-work]

LGTM and seems to work at least as well. Excited to get better type check handling, and some day I may find the time to address the new any's :-).

[JonasHelming]

@paul-marechal : Let's merge this!