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.
Notes
I started by looking at metalsmith-build-cache, but that wraps the whole Metalsmith build, so you have to split the build up to make it useful, and it proved quite tricky to split ours up in a sensible way that actually saved us time.
So in the end I created a caching plugin that wraps other plugins.
It gets passed:
It then creates a hash from the files matching the pattern and creates a marker
/.cache/metalsmith-cache-css-[some-hash]If that file already exists, we skip the plugin. If it doesn't, we run the plugin.
Results
It generally works great - the initial build time for
npm startis about 30 - 35 seconds on my machine, within-placeandlayoutsbeing the main timesinks, taking 20+ seconds in total.If I just cache the in-place and layouts steps, a fully cached run is about 4 seconds. It's quicker if I cache the css and javascript steps as well.
There's a small issue where the second run on identical files will still run the layouts step, because:
On subsequent runs, the layout step is skipped as expected.
To do
Better tests
I had a bunch of issues with tests on this, but I think I've mostly solved them. However, the single test I've now written makes use of
fsand I suspect adding a bunch of tests and running file ops for each of them will make the suite pretty slow, so it's probably worth figuring out a decent way to mock a bunch of stuff.Diff compiled code
We've talked about it before, but it would also be nice to have a way to diff compiled output between PRs and
main, to ensure things aren't going haywire - I did this manually when coding this up, but it was a hassle.Split the in-place and layout steps into smaller jobs
I haven't really thought about splits that would make sense, but for example, we could split these jobs into "components", "patterns", etc and have smaller jobs to run when we update files.
Or we could figure out how to only rebuild the files that have changed, via the cache wrapper's
patternsoption.