Gradual withOnyx deprecation

[roryabraham]

Coming from https://expensify.slack.com/archives/C01GTK53T8Q/p1725905735105989

Problem

The time and memory it takes to compile typescript in NewDot has been climbing. It currently takes about 1 minute and 4.5GB of RAM. This is problematic because it slows down development and we're encroaching closer to the 7GB memory limit for default linux runners in GitHub Actions. This is particularly noticeable in large files where changes take several seconds to report TS errors.
While the problem hasn't become too severe yet, it will only grow worse as time goes on if we don't take steps to address it. We've been able to stem the problem for now by increasing the default amount of RAM provided to the tsc process in our CI. But default GitHub Actions linux runners only have 7GB of RAM, so doubling the amount of RAM we give tsc again won't be feasible without upgrading from free to paid GitHub Actions runners.

Solution

Let's optimize TypeScript compilation times. More specifically, according to
Błażej's research the single biggest driver of high tsc memory usage is withOnyx - a HOC that has already been deprecated for some time.
Rather than undertaking a coordinated migration of all our withOnyx usages to its successor useOnyx, let's instead introduce a new PR check in our CI such that if you modify a file that uses withOnyx, the CI will fail on your PR, regardless of whether you introduced that usage. This way, we'll force an incremental migration as files are changed without putting in a large upfront investment. This low-urgency incremental migration matches the urgency of the problem.

[roryabraham]

cc @fabioh8010 @blazejkustra

[blazejkustra]

Thank you! Linked the issue in my PR

[roryabraham]

Created #49125 to implement this

[roryabraham]

Oh, sorry @blazejkustra didn't realize that you already had a WIP implementation.

Any thoughts on your approach vs mine? Mine looks much simpler, but it does target any deprecated code and not just withOnyx, but I'd maybe argue that's a feature not a bug

[blazejkustra]

Any thoughts on your approach vs mine?

It is indeed simpler, but as you described it can fail for other deprecated imports as well - I'm unsure how often we use other deprecated imports that we can't migrate, that might be a slight problem 🤔

The script I prepared has one advantage, it compares number of withOnyx on main with the current branch. The check is successful when you migrate at least one withOnyx which I believe is more practical. So you don't have to migrate withOnyx in all files you edited, just one so it's less friction for contributors.

[blazejkustra]

On the other hand with your implementation, the migration will be completed faster. That's why I think both approaches are fine 👍

[roryabraham]

Going to close this as completed for now. We'll see how it goes in practice, but there's no more TODO here