Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR removes the monorepo build artifact caching added by #1081 and #1142, also removing the need for #1175. In practice, my observation has been that most of our tasks are either very fast (e.g. esbuild) or already cache automatically (e.g. Cargo), and that for the ones that aren't super fast (e.g. Vite build in components or editor), Nx usually doesn't cache those anyway because their dependencies changed. Furthermore, it requires a lot of configuration to correctly identify cache hits; so far we've only been specifying the outputs of each task and not the inputs, so Nx usually reruns tasks unnecessarily because it sees changes in the output artifacts of downstream tasks and conservatively assumes that those might affect things. On the flipside, I've also often found myself running
rm -r node_modules/.cache/
just to be sure that Nx isn't caching things incorrectly. Specifically, some of our scripts (e.g.wasm-bindgen
) don't delete the contents of their output directory before writing to it, so if they aren't writing as many files as they were before, Nx will still pick those up and put them in the cache even though they aren't outputs of the current task run. In theory we could deal with this by manually deleting these output directories before writing to them, but even that doesn't really seem feasible: for instance, if we were to always deletetarget/
before running Cargo, that would get rid of its own caching abilities, which wouldn't be worth it.Checklist