Is moon a replacement for webpack (and other) caching?

[snspinn]

I've recently run into issue with my builds around caching of files in yarn and webpack.. among other things. Given that we're all using a variety of framework -- with their own opinion -- having moon being thrown on top makes the whole question of caching get a little fuzzy. Unless you're someone that understands the details of caching (of each tool in the chain) this can often give the feeling of non-deterministic behaviour in the build system. Seems like people (me) just end up disabling all these cool features and "making coffee" ten times a day.

Is moon a replacement for caching like yarn (probably proto's concern) or webpack? If not by default, can it be? Is it recommended?

Can see situations where build debugging may be to incrementally disable/re-enable caching. Wondering if it should go from moon "down" or from underlying tooling "up".

[milesj]

@snspinn moon is not a replacement for yarn/webpack caching in regards to their specific caching implementation. moon's caching is primarily for remote caching, in which build artifacts can be uploaded and downloaded across machines.

Let's use webpack for example. If you have a webpack config that compiles the application to a build directory, relative from the project root, then that build directory is what moon caches, since that's the generated output files. moon wouldn't cache any of webpack's internal caching that it does, just output files.

Now say if another developer runs the webpack build process on their machine, and you all are using remote caching, then moon will download that build directory instead of re-running the webpack build process. If the webpack build takes 5 minutes to run, and downloading the cache takes 30 seconds, that's 4 minutes and 30 seconds saved.