Asset build cache

[thedodd]

As discussed in various locations, and most recently in #185, it would be beneficial to have Trunk use an asset build cache along with a hashing pattern to reduce the amount of work needing to be performed when changes are detected.

With rustc/cargo this is handled for us quite nicely, and I do not think there is any reason to alter our behavior in this case.

For other pipeline types, it seems logical to allow them to define their own hashing and caching strategy, as different pipeline types will have different requirements. Take for example the copy-file pipeline vs the sass pipeline. The sass pipeline will need to take into account not only the index sass file being targeted, but also any other files which may potentially be included/used in that index file. The sass pipeline will need some specialization which other pipelines may not.

General Pattern Discussion

Current Pattern

We are currently using two directories as part of our build pattern (really only one, as the stage dir is a temporary child directory of the dist dir):

pub const DIST_DIR: &str = "dist";
pub const STAGE_DIR: &str = ".stage";

The stage dir is used as a per-build staging area where artifacts are collected. Once the build completes successfully, the dist dir is cleared, and all of the artifacts in the stage dir are moved over.

Next Steps

• The current pattern does not persist any info related to an artifact's source. No hash, nothing.
• We will need to preserve a hash of the source in order to compare an object to determine if it needs to be processed again.
• What about the sass example where there are many files being @used? How should Trunk handle this?
  • Do we bite the bullet and do some deep analysis of the sass code? This seems like we would be asking for a lot of maintenance work.
  • Do we update our sass lib (update to dart sass) and hope that it provides a nice mechanism we can use to build a manifest of sorts specifically for the sass pipeline?
  • Seems like some additional investigation is needed here. Probably best to — at a minimum — update the sass pipeline to use https://github.com/sass/dart-sass directly via CLI invocation (auto download and such).
  • Work smarter not harder: looks like dart-sass has its own --watch mode. Perhaps we could leverage that to resolve any issues related to sass caching/hashing &c.
• For other asset pipelines, it seems like our work is a bit easier. Not as in-depth.
• Should this be the beginning of the Trunk manifest system?
  • See https://github.com/thedodd/trunk/issues/171 & https://github.com/thedodd/trunk/issues/9 for more context.