Open hralexander opened 2 years ago
Note:
any
any
(which is the any
produced during type unification)I've seen two other teams whom converted legacy codebases to strongly typed, using these directory specific rules. Therefore this is one possible approach.
Adding to this ticket, since I am not sure where else to document/place.
Did an analysis of our tsc compilation performance. The summary:
any
types.
Done on SHA: 6069238925a131aaf3782fe416bc726d2fa8e4e9
$ yarn run tsc --extendedDiagnostics --noEmit
Files: 2224
Lines: 383115
Nodes: 1461193
Identifiers: 492462
Symbols: 602854
Types: 205918
Memory used: 724069K
Assignability cache size: 102864
Identity cache size: 5731
Subtype cache size: 12526
Strict subtype cache size: 9487
I/O Read time: 0.06s
Parse time: 0.69s
Program time: 1.73s
Bind time: 0.55s
Check time: 6.96s
Total time: 9.25s
✨ Done in 9.63s
$ yarn run tsc --noEmit --listFiles | xargs stat -f "%z %N" | npx webtreemap-cli
Size checked: 11.9 MB Size from node_modules: 57.1% Top 5:
Comparison/example repo:
Ours:
Why are we so fast?
any
types4203 results in 304 files
Temporarily moved to typescript@4, so can do performance tracing based on time. (Also temporarily fix errors found with typescrip@4.) Got the tracing to run, but the analyzer gives errors when opening in the file in the GUI. If we hit a future problem with slow compilation speeds, then we can dig into this further. (a.k.a. as we start removing any
types, we can watch our performance speeds and debug as needed.)
https://github.com/microsoft/TypeScript/wiki/Performance-Tracing
Analyze the codebase and identify areas where we can begin to build out strongly typed objects within the UI. The goal is to build a living model of code that utilizes more strongly typed objects that the team can adopt more broadly over time.