GeezerVison

Sheetal Nandi (@sheetalkamat) Very nice. Just tested this using the test case from #33329 and confirmed that recompile time is now very similar to gulp-tsb

/cc Johannes Rieken (@jrieken)

Ryan Cavanaugh (@RyanCavanaugh) Daniel Rosenwasser (@DanielRosenwasser) Do you think the name of the flag is ok or otherwise please suggest something. Note that its not just check that gets disabled but also ".d.ts" emit of these indirectly importing files.

skipIndirectImportProcessing?

In an incremental build, skip type checking and .d.ts file generation for files indirectly importing changed files.

?

assumeSemanticChangesOnlyImpactDirectDependencies

You left a laugh reaction, but I'm like half serious

That’s perfect; I’m only half laughing 👍

• assumeSemanticChangesOnlyImpactDirectDependencies
• skipIndirectImportProcessing
• yolo
• assumeChangesDoNotImpactIndirectDependencies
• assumeChangesOnlyAffectDirectDependencies 👈

assumeApproximateDependencies?

Sheetal Nandi (@sheetalkamat) this PR added at least one test that causes long-path problems on git for windows. Could you try to shorten it?

error: unable to create file tests/baselines/reference/tscWatch/emitAndErrorUpdates/config-with---assumeChangesOnlyAffectDirectDependencies-and---declaration/updates-errors-when-file-transitively-exported-file-changes/when-there-are-circular-import-and-exports.js

There is a flag for git that might resolve the issue, but it seems better to just rename the test.

I'm probably misunderstanding the point of assumeChangesOnlyAffectDirectDependencies, but I'm testing it on a large project on 3.8RC, and it doesn't seem to have any effect. For historical reasons, our project does not use modules, just namespaces at the file level. With the assumeChangesOnlyAffectDirectDependencies option on (and incremental), I make a test change in a file that is referenced (as far as I can tell) in a three other files. However, I see most files in the project are built, and it's still taking me 20 seconds to build our project when a small change is made.

Thanks for all your hard work on this great project. Happy to provide any other diagnostics / output that would be of help.

Unfortunately that's as expected - codebases with global files don't have an explicit dependency graph, and every file is considered a direct dependency of a global.

Daniel Rosenwasser (@DanielRosenwasser) we’re having the same issue as mathias999us, but I don’t understand your comment. Can you clarify what’s the difference between codebases with and without global files?

Previously we specified an array of files in the files property in tsconfig. But after getting rid of this array, the problem still persists and assumeChangesOnlyAffectDirectDependencies doesn’t seem to do anything, neither as a compiler option in tsconfig, nor as a CLI flag.

What could we be doing wrong?

Many thanks (and apologies if this is not the right place to ask)!

If your files are all global, TypeScript assumes that they are all compose into one big ball of globals that can impact each other in arbitrary ways. Regardless of any sort of arrangement based on file order or /// <reference path="..." /> directives, globals cause non-local errors and changes in types on every file in your project, so there's no assumptions we can make based on efficiency and independent checking.

For example, imagine 3 files

// a.ts
var x: string;

// b.ts
var x: string;

// c.ts
var c: string;

Now imagine another global file comes along

// d.ts
var x: number;

That declaration of x conflicts with other declaration of x. To model that, every single global file is effectively a direct dependency of every other global file.

Or, as a more 3D diagram might illustrate

My recommendation is to move off of global code (which our team is in the process of at #35561)

Daniel Rosenwasser (@DanielRosenwasser) Thanks for that straight-forward (and comical) explanation. However, our situation is still slightly different than the example you gave. We house all our code in namespaces at the file level (old-style TypeScript modules). I would think the TypeScript compiler should be able to determine that it only needs to compile other files that reference the namespace whose content is being changed.

Namespaces are really just declarations that sit in the global scope - in theory we could do more work to say that when all files contain exactly one namespace, we can synthesize the dependency graph after type-checking and try to reuse it between compiles - but that's actually very different from the logic we use to establish dependencies between files today and would be a lot of work. My gut says that a better way forward is to migrate to modules since that's where the majority of our investment as well as the community has been going. Additionally, we've been building some tooling for ourselves to do that which you can leverage.

Great addition, thank you for the awesome work!

Is it safe to always set assumeChangesOnlyAffectDirectDependencies to true if a package is marked free of sideEffects through package.json? I became curious about this while building a modern library bundler tool.

Kristóf Poduszló (@kripod) they're not necessarily related - you can have top-level statements that cause side-effects, but don't add or remove any global declarations.

This feature is really about enabling faster iteration time by only recompiling the files that directly import a file. It relies on an assumption that given A <- B <- C, a change to A won't impact C (which is not guaranteed to be true).