Delete CacheLayer

[zepumph]

Since adding a new Transpiler, we have some buggy code with CacheLayer I believe. It doesn't know when to break the cache for pre-commits. @samreid is this right?

[zepumph]

I'm more scared about it this now, because I really don't want to expose the need to regenerate all phet-io APIs for each repo. It seems like that cacheing, for multiple pre-commit tasks run in a row, is still working. Perhaps we need to keep that feature?

[samreid]

Some thoughts, no particular order:

1. I would prefer not to have a watch process that invalidates caches
2. I would prefer not to try to leverage the SWC watch process for caching
3. Adding a new cache strategy like "did this test already pass within 5 minutes" could be buggy, and could "kick off" multiple tests at once if precommit hooks run in parallel anyways.
4. We recently got a speed boost in generating phet-io apis by caching in the web server layer.
5. We already opt out of testing when running in phet-io-sim-specific itself.
6. Pre-commit tests are supposed to be fast and independent. I believe that a more sophisticated "multi-repo-aware" strategy is the correct solution to this problem. But I do not know how developers could make that automatic.

Let's discuss

[zepumph]

This issue has been sitting here for a month because I can't tackle it until we create a solution so that pre-commit hooks don't re-generate phet-io apis for every stable sim for every repo. I believe that is an unacceptable amount of time that devs are wasting right now.

[samreid]

Notes from today's dev meeting:

SR: Do we need MK for this agenda item?
SR: Should I add a sim+dependencies hash key for caching?
SR:
~/phet/root/buoyancy$ time grunt compare-phet-io-api
Running "compare-phet-io-api" task

Done.

real 0m52.597s
user 0m9.903s
sys 0m8.757s
JB: Ideally the pre commit hooks would be fast and complete
CM: We should be able to rely on pre-commit hooks to not break CT. I am okay waiting a few seconds longer for that reliability.
SR: Should I delete the broken cache layer for now? I think so.
SR: How important is adding a cache for that?
SR: Do we have to run the pre-commit hooks using git/hooks, or is there something else like ‘grunt pre-commit’
Let’s consider that a preview, and check in with MK next time.

[samreid]

I changed the cache so it is always a cache "miss". This way we will never get an incorrect result, but it will take longer if multiple repos want copies of the same API(s).

[zepumph]

I believe part of the solution to this problem is note phetsims/perennial#420. In that issue I want a one stop shop that answers the question "is my local codebase acceptable?" Some devs are ok with pre-commit hooks extending the time they take by an order of magnitude to account for redundant stable-phet-io-api checks, and others are not. When this is unacceptable for devs, often they turn off phet-io-api comparison in their pre-commit task, and rely on running their own check of it before committing, and CTQ as a fail-safe. My hope is that a general and optimized codebase check can be run via a grunt task, and will be able to batch the redundant and expensive tasks that currently weigh down pre-commit hooks because they have to be able to be run on just a single repo.

So I believe this issue is most likely in a good state so long as I understood the notes from the dev meeting last week.

[samreid]

There are several TODOs listed for this issue. Want to leave the issue open and deferred until phetsims/perennial#420 is ready as a replacement? Then we can delete CacheLayer altogether.

[zepumph]

I think deleting this unused code is good to do now. The next issue probably isn't going to use the same type of caching, since it doesn't need to persist in the same way. Maybe? Not totally sure, but it is right here in the below commit if/when we need it.