List all transitive dependencies for each tsconfig

[samreid]

As described in microsoft/TypeScript#46153, project references are designed so that if a project imports from another project, it should be listed in the direct references (not transitively). According to the issue, that could address the false positives and false negatives we have been seeing.

This would be an alternative to the monolithic (one file/no project references) strategy or having to clean each time as described in #1243 (comment).

[samreid]

I did not see an existing lint rule that could help enforce this new requirement. I checked the rules at https://www.npmjs.com/package/eslint-plugin-import. I don't see an easy way to automatically update the tsconfig files from existing imports. Maybe we would write our own lint rule that checks that any import has a direct listing in references? But we would want to make sure that works for tsconfig.json and tsconfig-module.json. If we write our own lint rule, it would flag as an error at the import site, but really it would probably indicate that a project reference needs to be added to references.

It seems it would be much simpler to adopt the monolithic tsconfigs as described in #1243 (comment). As far as I understand, those have the following disadvanatges:

• Up front cost to specify the monolithic tsconfig files
• Monolithic seems slower at detecting "there are no changes", taking 5 sec instead of 1 sec, see Prune tsconfig/all/tsconfig.json #1241
• The proposed monolithic scheme specifies sim mains as entry points and would skip files that are never imported. (workaround is to import those files or add them as entry points).

Project references are indicated for modularity and speed, but are causing more complications.

Maybe it would be good to touch base at dev meeting before spending more time on this.

[samreid]

In today's discussion, we agreed we would like to explore the monolithic tsconfig approach, but having **/* to capture every entry point. These will replace the project-references versions. Not sure if we should keep those around in case we go back to them in the future.

@zepumph wants to time **/* and see how it goes before changing everything.

[samreid]

On my macbook air, the timing is like:

Case	Initial (sec)	Incremental/no changes (sec)
Geometric Optics	4.987	1.570
tsconfig/all	13.983	5.403
tsconfig/all (no images/mipmaps/sounds)	11.106	3.100

In experimenting with using tsc in my workflow, I felt like 3.1 was a good enough improvement over 5.4 that I feel like commenting out the data-oriented files images/mipmaps/sounds, at least from the all file.

I thought our tooling would need to change, but it turns out running -b in a non-composite project has the same behavior as running without -b. So that step doesn't seem technically mandatory.

[samreid]

From review with @zepumph:

• Seems promising and much simpler, easier to maintain. Will likely solve the "false positives and false negatives" issues.

Next steps

• Add a comment to the sim/common repo tsconfigs that say "this was autogenerated", and autogenerate with grunt update. Maybe even other repos without grunt update, like aqua.
• Update tooling so we aren't using -b

We also agreed that this seems like an improvement and we can commit/push and work on the improvements above as next steps.

• Use "excludes node_modules" and build/ instead of "includes js, images, mipmaps, etc.". UPDATE

My experience from writing transpiler.js was that it was much more efficient to specify the entry points where we expect code. Instead if a repo has other needs, it could be listed in package.json.

• Maybe add all repos, but use "include" pattern "*.ts"?

We have to keep allowJS: true listed in tsconfig for type checks to work, since our TS code calls into JS code. Maybe that would work to set the entry points though? Also, I'm concerned this will explode our type check times.

• Autogenerate the all/tsconfig too?

Would this be a new grunt task?

[samreid]

I removed the stale code comment, closing.