Ensure our project references include transitive references

[jakebailey]

Without #30608, there's a chance that building a single project may not actually cause another to be invalidated, so we must explicitly verify that all are listed.

I also added a script which says when something's wrong.

Pulled out of #55273 (comment) since this change is unrelated.

[andrewbranch]

Sheetal is the expert here, but this doesn’t seem right to me. In both of the referenced issues, users were trying to take a direct dependency on a transitive reference and were surprised that it doesn’t redirect the reference or invalidate the build when the transitively referenced project had changes. That’s not what we have. tsserverlibrary/tsconfig.json doesn’t need to reference deprecatedCompat or typingsInstallerCore because it doesn’t directly import those things. To quote myself from one of the referenced issues:

the way I have always set up project references is if I import directly from another project (as you imported projectC from projectA in your example), I list projectC as a reference of projectA. On the other hand, if I use exports from projectC only indirectly through projectB, I only list projectB as a reference of projectA.

[jakebailey]

That's how it feels like it should work, yeah, though #55273 (comment) seemed to imply otherwise unless I'm misunderstanding something here.

[andrewbranch]

I also think #30608 was just an ancient bug that was actually fixed?

I think I also had issues recursively compiling all nested project references, but the ---build options seem to handle that now, and Visual Studio seems to handle it fine also (perhaps I just didn't know about it then, or didn't upgrade yet).

[andrewbranch]

From @sheetalkamat:

i think if you change something in deprecatedCompat, it wont build tsserver library since its not direct dependency unless server needs to be built too. (which is what may be is intended)

I think this is intended; why would it not be? If some change in deprecatedCompat doesn’t require server to rebuild, why should it require tsserverlibrary to rebuild when tsserverlibrary only depends on deprecatedCompat through server, which is unchanged?

[jakebailey]

Yeah, I guess feasibly I can just not do anything except list the things that are actually imported in each project (what I did originally) and be fine?

[andrewbranch]

Aren't we protected from accidentally importing something external without including it in references because it will trigger the “all inputs must be within rootDir” error?

[jakebailey]

Yes, though this PR in particular is about the opposite direction of referencing things that are unused within the project itself.

[sandersn]

Looks pretty good with a few suggestions

[sandersn]

As others point out, I don't know if this is needed, but the code itself looks OK.

[sandersn]

minor quibble: there's no reason to pass seen around instead of referring to it from inside getReferencesWorker

[jakebailey]

Yeah, I had it like that before but switched it to this. I'm not picky but I'm too not sure if this PR is still needed.

[jakebailey]

I'll just close this; if it turns into a problem again we can revive it.