Drop per-pipeline transformation cache

[devongovett]

This was extracted from the db2 branch. As discussed in previous core team meetings, this removes the per-pipeline transformation cache. This is only hit when:

• The file was "touched" in some way that triggers the watcher to invalidate it, but the content didn't actually change. For example you hit save without making changes.
• You changed the content of an asset, and then changed it back. Could happen when switching between branches.
• The content of a config file (e.g. package.json) changed in a way that didn't actually affect the config contents (e.g. different key). This is perhaps the most likely scenario.

Other cases are already handled by the request graph which won't even run an asset request that isn't invalidated.

Given the limited cases where it would be hit, the transformation cache results in a lot of complexity and issues. It is difficult if almost impossible to compute the cache keys for transformations ahead of time. You need to know all of the files, configs, dev dependencies, options, environment variables, etc. that will be used when doing a build for an asset, all of which require the request graph to know, so the transformation cache couldn't even be used standalone. In addition there were some bugs because it's hard to associate each of these to the correct plugins, especially dev dependencies which are be loaded on demand. For these reasons, we decided to remove the transformation cache and just rely on the request graph to know when to rebuild.

One other benefit of this change is that each asset only has one key in the cache now, whereas previously the cache would grow unbounded as changes were made.

In the future perhaps we can find other ways to address the above cases if we find this change results in widespread performance regressions.

[mischnic]

AFAICT, Asset.hash is completely unused now (only set and never actually read)

parcel/packages/core/core/src/types.js

Line 172 in 8ba5523

hash: ?string,

[bb010g]

Does this effect the caching impact of babel.config.js compared to babel.config.json?

[devongovett]

No. JS files are still harder to cache because they can produce non-deterministic results, and we have to take into account all of the dependencies they import/require etc.