persistent cache

I had an idea when thinking about general brunch optimization and the issues with sass being so slow. Brunch could cache compiled, pre-concatenated output to disk (perhaps in a .brunch-cache directory). It would also need to keep a reference of the compilation time (fs.utimes may be sufficient) and the dependency list. On the next instantiation of brunch, before bothering to compile again, it checks to see whether it is necessary to do so.

Users could opt-out of all this in config. Also, potentially this behavior doesn’t even kick in unless overall compilation time passes some threshold, like 5s maybe. Or maybe that time limit is actually applied in a granular way, like any source file that takes >2s to compile gets its compiled output cached to disk.

I’m pretty sure it would be a massive benefit to a project I have which includes some slow-compiling sass and less that hardly ever gets edited.

Thoughts?

[monokrome]

The default directory shouldn’t be outside of project, but it should be possible to configure it outside of project. If it’s outside of the project, that’ll be even more confusing to users.

If brunch fails with some type of file and a cache is breaking things, a user should be able to know to clear the cache with relative ease. If there’s some magic thing persisting state between brunch runs and putting files where people don’t know about / expect them - it’s going to confuse people when there are issues.

Also, the point of /tmp/ is that data there is temporary and not to be used for persistence. This is the wrong place in Unix filesystems for the cache. The right place is within the project directory, or optionally somewhere like $HOME/.brunch/cache.

There should probably be a global brunch configuration this type of thing, like $HOME/.brunch/config.coffee because different users might want to place these in different places. This is not really a project-specific feature as much as a user-specific feature.

In example, as much as it might bother a coworker that it takes 20 seconds for them to build our project on their machine - it might in turn bother me that I have this cache sitting around when it only takes me 4 seconds on my machine. Maybe I prefer to wait the 20 seconds and not have extra confusion/overhead in the whole process.

This file could still be relatively simple:

module.exports =
    cache:
        enabled: true
        path: '~/.brunch/cache/'

and the default values can be:

• enabled: false
• path: ./.cache

As a user, I expect the first place to look is in the project directory, so this organization would provide that the data is persisted and easy to find while not defaulting the behavior or being overly confusing.

[es128]

Ok. I relent.

I realized over the course of this discussion that a big reason the 20s bothers me is because I use this project for testing when hacking on brunch itself, hence needing to restart all the time. But clearly, that’s only my problem, and there are plenty of other solutions for it.

I suppose the effort would be better spent converting the problematic sass files to stylus in the case of the project, or on other features in the case of brunch itself.

And @Nami-Doc if what you were looking for was a way to get the compiled files without the concatenation step, there will be a solution for something like that in #616.