Seems to re-browserify everything after restarting dev server about browserify-rails

[cymen]

I seem to recall that being normal. I realize that's probably not the answer you were hoping.

[johnolek]

Hey thanks for the reply. It's good just to know it's normal and that there's no way around it right now. I wonder if it would even be feasible to check the cache on startup? Maybe something I'll look into contributing myself if I can. Right now one of our apps spends about 2 minutes browserifying everything every time we restart the dev server, which can be pretty annoying.

[cymen]

I'm on really shaky ground here as it has been a while since I looked into that part of the code and debugged it but...

I think the issue is that the browsery-incremental cache is put in a temporary directory related to the assets pipeline. So it's not hard coded to an external directory. And I think that temporary directory name/path changes on restart. So what you might look to do is to make an option to set browserify-incremental, if it supports it, to always put the cache in a given directory. Or do some magic around stop and restart to somehow persist the cache. That might get you what you want?

[cymen]

I had to look, so browserify-incremental has a cache_file_path parameter and we are indeed setting that:

https://github.com/browserify-rails/browserify-rails/blob/master/lib/browserify-rails/browserify_processor.rb#L193-L196

cache_file_path = rails_path(tmp_path, "browserifyinc-cache.json")
command_options << " --cachefile=#{Shellwords.escape(cache_file_path)}"

So one could indeed add a configuration option with an external path (perhaps called persistent cache directory or something like that) and if that is set, use that. I'd suggest starting by examining the paths that are in use now for the cache -- I seem to recall while it looks like from the code they might be reasonable, that there was some server-start-random-value in it that would cause the symptoms you're describing (of not persisting between restarts).

[gnclmorais]

We’re experiencing this as well, after having upgraded sprockets from 3.7.2 to 4.0.0. Everything gets compiled again and again.