Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to ignore tmp/cache when precompiling locally #3014

Closed
rhulse opened this issue Sep 14, 2011 · 0 comments · Fixed by #3015
Closed

Need to ignore tmp/cache when precompiling locally #3014

rhulse opened this issue Sep 14, 2011 · 0 comments · Fixed by #3015

Comments

@rhulse
Copy link

rhulse commented Sep 14, 2011

I changed compressors to Google Closure to get around issue #2537 with uglifier reordering my files.

I tested the precompilation on my development machine. Rails forces env to production in this case.

After precompiling the generated JS did not reflect the change in compressor.

It appear that Sprockets is using the cache in tmp during static compilation instead of what is in the config and assets folder. On a dev machine tmp this is unlikely to be cleared out; in production (with Capistrano) you get a new tmp folder with each deploy.

On a local dev machine this could create issues for people who have to precompile locally if they change compressors (or some other change that the cache will ignore).

Anyway, it doesn't seem like a good idea to use the cache if it exists when precompiling - it will cause unexpected results, which in my case has wasted 2 hours this morning.

A config change (such as changing the compressor) should Just Work.

ref: https://github.com/sstephenson/sprockets/issues/195

gberenfield pushed a commit to gberenfield/rails that referenced this issue Sep 14, 2011
…recompile

Clear cache before of each precompile to avoid inconsistencies. Fixes rails#3014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants