Bug Report

I've been analyzing the performance of the upgrading https://github.com/signumsoftware/southwind/tree/cfe00a16d763cfecbc061da70271781698171c1f to the latest version of Typescript:

The solution consist in a dozen of csproj with three projects containing .tsconfig and depending on each other, each in a different git submodule:

Southwind.React -> Signum.React.Extensions -> Signum.React
https://github.com/signumsoftware/southwind/blob/cfe00a16d763cfecbc061da70271781698171c1f/Southwind.React/tsconfig.json
https://github.com/signumsoftware/extensions/blob/1f4e089233981033d646778f6102edb9747654ec/Signum.React.Extensions/tsconfig.json
https://github.com/signumsoftware/framework/blob/3b626662396d35d21ff495bf99bf9ac91714f8a4/Signum.React/tsconfig.json

I've updated all three projects:

NPM typescript "4.2.3" to "4.3.2"
NuGet Microsoft.TypeScript.MSBuild "4.2.4" to "4.3.2"

And I've analyzed the following scenarios:

Compiler

• CSharp only: Compiling in Visual Studio 2019 with <TypeScriptCompileBlocked>to have an idea of the C# part.
• VS: Compiling in VS2019 both C# and Typescript using Microsoft.TypeScript.MSBuild
• tsc: compiling by command line in Southwind.React folder

Scenario:

• Clean rebuild of the full solution in VS or ´yarn run tsc --build --force`
• Build solution in VS or yarn run tsc after changes in different files (just adding and removing empty lines):
  * Navigator.tsx (in Signum.React, deeper dependency)
  * AuthClient.tsx (in Signum.React.Extensions, middle dependency)
  * MainPublic.tsx (in Southwind.React, entry point)
• Build with no changes.

For each case I've taken three measures and calculated the average:

Am I doing something wrong in the .tsconfig files? or is this an important performance regression?

Also note how when using TypeScriptCompileBlocked VS is able to detect the projects as "UpToDate" (00:00), while with TypeScript activated he is forced to recompile this projects most of the time (some times not, but I can not reproduce it reliably).