I am trying to get barista up and running in a Rails 2.3 application (that may not be moved to a new version of rails for the time beeing..). I switched the app to bundle so I added the following gems to my Gemspec:
gem "barista"
gem "json"
Then executed bundle install which run through. Now as far as I understand to "compile" the coffeescript there is a rake task that comes with barista. But it doesn't seem to be installed properly so I can use it with rake. I.e. when I execute rake -T there is no barista:brew
I saw a pending pull request on git hub suggesting to add require 'barista/tasks' but that only resulted in rake not finding it. So what am I doing wrong or more general how do I get up and running with barista on Rails 2.3.x?
It has been some time ago since I used Barista and I have it not in use in any project, so I cannot verify it.
But I remember that one advantage of Barista is, that it waits serving a request until a modified CoffeeScript file is recompiled. This ensures that the browser doesn't request an outdated file.
So there is no need to compile the CoffeeScript files with a Rake task.
CoffeeScript itself comes also with a watch function, that compiles CoffeeScripts when a change is detected:
coffee -w /path/to/scripts
The reason why I stopped using Barista is simply that I discovered Guard. So I wrote guard-coffeescript to compile my CoffeeScripts in the same moment I save the file.
Guard-coffeescript has some advantages over Barista and CoffeeScript:
Fast and low CPU consumption because it relies on file system modification events.
Can be configured in many ways, e.g. multiple source folders and output folders.
Immediate feedback when an error occurs, even with system notifications like Growl.
Note that Rails 2 support for Barista is, according to Barista's README, "untested" (it was originally built for Rails 3 only), so there may be compatibility issues. Also note that you need either therubyracer gem, or the node binary on your system's PATH (or any of the other JS runtimes supported by ExecJS).
Try this:
Add a file named foo.coffee to the folder app/coffeescripts with the contents
alert 'Hello, Barista!'
Now add <%= javascript_include_tag "foo" %> to an ERB file and load that page.
You should get the alert, just as you would if the compiled foo.js were in public/javascripts.
I've successfully integrated barista and rails 2.3.14. In development, when I ask for a js file, the coffeescript file is found and compiled on the fly.
I also successfully ran the barista:brew rake task and the js files were generated.
I did notice that for production, unless I include an ExecJS compatible compiler, I need to precompile my js files before a push, which might be another +1 for the guard solution by #netzpirat.
For reference - I'm using Barista 1.3.0 and coffee-script 2.2. Not sure how that affects things, but thought it was noteworthy.
Also, I added a line to load the barista tasks in my Rakefile:
# in my Rakefile
load "barista/tasks/barista.rake"
Related
My Rails 5 application is behaving weirdly. The application is on heroku.
I am using the gem tinymce-rails. Recently, this gem got updated to version 5 which uses new functions. After deployment I faced an issue where one of the plugins (the link plugin) could not be loaded due to using the old syntax.
I am using chrome to open the website. For some reason the tinymce plugins javascript files are not up to date. They also don't have that fingerprinted name with the hash in the end. All other javascript files do however.
I ran heroku run rake assets:precompile; heroku run rake assets:clobber;. It was no good.
I then tried to open the website in incognito mode and found that the tinymce plugins are the up to date ones. Still though without the fingerprinted file names.
How can I force that the old plugin javascript files be invalidated? I will not have control over my users to ask them to clear their caches.
How can I force using the fingerprinted files? I have inspected the heroku server file system and found assets/tinymce/plugins/link
having both fingerprinted and non-fingerprinted files however the non fingerprinted files were the ones used.
I have a templates directory in my assets folder on my Rails setup which hosts my templated-HTML files. I've implemented a partial system where I can load text snippets into each template so long as it has a .erb file attached to it. The partials are prefixed with an underscore, so /assets/templates/_form.html is a partial which is included inside of /assets/templates/edit.html. This works, but there is an issue when I run assets:precompile.
The assets:precompile command will precompile the _form.html files as well (since they're located inside of the assets/templates folder) and I don't want this to happen since they can't be precompiled (since any erb variables are missing and so on).
Is there any way I can inform the rake assets:precompile command to ignore certain files (in this case files that have an underscore infront of them)? Does someone know how to do this? Or can someone point me to the github repository which has the source for the rake assets:precompile command?
In Rails 3.2.8 you can find the source for the rake task definition here.
What you're asking has been brought up at least once in Sprockets issues tracker
https://github.com/sstephenson/sprockets/pull/86
joshpeek added a new stub directive in Sprockets 2.2 which looks like a promising solution to 'ignoring' certain assets from the pipeline.
Rails 3.2 doesn't support a version of Sprockets anywhere near 2.2 and there doesn't seem to be any intention on doing so before Rails 4 from what I've read (though I'd love to be wrong about that). Here's at least one closed issue (no action taken) requesting an upgrade to 2.2.
https://github.com/rails/rails/pull/5984
For your situation though, it seems to me that you might be using app/assets incorrectly. I can't offer an alternative solution as I don't know enough about your setup/usage to say definitively, but as you said, files with .erb in app/assets are going to be processed by Sprockets.
I've seen various convoluted and generally ineffective solutions to performing lazy asset precompile in Rails. As a backend developer I don't particularly want to recompile assets I never touch every time the program deploys, but because assets are loaded in Capfile via load 'deploy/assets', and not by defining a task in deploy.rb, I can't think of a way to conditionally disable it.
The behaviour I'm after is to use cap deploy for regular with-precompile deployment, and to use cap deploy:no_assets to skip asset deployment.
Both turbo-sporocket-rails and the that auto-skip scripts have some pitfalls (I will mention later). So I use the following hack, so I can pass a parameter to skip asset pre-compile at my will:
callback = callbacks[:after].find{|c| c.source == "deploy:assets:precompile" }
callbacks[:after].delete(callback)
after 'deploy:update_code', 'deploy:assets:precompile' unless fetch(:skip_assets, false)
This script will change the built-in asset-precompile hook, so it will be hooked based on the skip_assets parameter. I can call cap deploy -S skip_assets=true to skip asset precompile as a whole.
For me, turbo-sporocket-rails still takes minutes to do the checking when nothing has changed. This can be crucial when I need to push a fix to the server asap. Therefore I need my force-skipping method.
rails4 addresses this issue with it's new version of sprockets, by only precompiling assets that have changed. In the mean time, for your rails3 apps I recommend the turbo-sprockets-rails3 gem.
This gem started out as a set of patches for sprockets-rails by Nathan Broadbent, which were not merged into master because the problem was already addressed in rails4. From the README:
Speeds up your Rails 3 rake assets:precompile by only recompiling changed assets, based on a hash of their source files
Only compiles once to generate both fingerprinted and non-fingerprinted assets
And:
turbo-sprockets-rails3 should work out of the box with the latest version of Capistrano.
I can confirm that it works well for me on rails-3.2.x apps deploying with Capistrano.
As a side note for GitHubbers, the original pull request is an excellent example of how to submit code to an open source project, even if it wasn't merged.
This gist looks very promising https://gist.github.com/3072362
It checks your git log from the last deploy to now to see if there are any changes in %w(app/assets lib/assets vendor/assets Gemfile.lock config/routes.rb) and if so, only precompiles then.
So just trying out Rails 3.1-rc1 with the Sprockets asset pipeline:
I run rake assets:precompile
and I get the /public/assets directory and the application.js file the MD5 hash:
application-266b6b0b4fbd28fc01145d90a4158b2f.js
But the problem is this:
When I update my JS and run rake assets:precompile I get more JS files and it doesnt delete the old ones.
I'm note sure how it works - the browser only picks up the first one and I have to manually delete the old ones. Which doesnt seem like how it should work.
Just a side gripe: It seems I have to run rake assets:precompile every time I change something. Which is painful.
(I guess there needs to be some docs on how this all works).
Thanks.
The name of js file is <file name>-<hash>.js.
That's made so that when you deploy new version of application to the production server your visitors would have to load new js file as well. The hash ensures that they will not have mixed up new application and old cached js that may break entire application taking into account dynamic nature of the web this days.
In most deployment scenarios you will have your app in new directory on the server and you will not have old compiled js files there.
I'm working to install Jammit on my Rails 3 app and then to deploy to Heroku.
I installed the Jammit Gem, and configured assets.yml just fine, it works on dev. But when I pushed to heroku, the files were 404'ing.
Jammit's Usage instructions say: "You can easily use Jammit within your Rakefile, and other scripts:
require 'jammit'
Jammit.package!
I'm not following where/how that works. Running Jammit in my sites command like on the Mac yields a command not found.
Any Jammit users able to help me understand how to move to production with Jammit?
Thanks
I'm using jammit on a Rails 3.0.7 app, on Heroku
gem "jammit", :git => "git://github.com/documentcloud/jammit.git"
I have this in a rake file, to package up the assets before I commit/deploy
desc 'jammit'
task :jam => :environment do
require 'jammit'
Jammit.package!
end
And this in .git/hooks/pre-commit so it is done automatically
echo "jamming it"
rake jam
git add public/assets/*
git add public/javascripts/*
By default, the expires time on Heroku was only 12hrs, to increase it (because I have a cache-busting scheme that I am confident in) I put this in config/initializers/heroku.rb
module Heroku
class StaticAssetsMiddleware
def cache_static_asset(reply)
return reply unless can_cache?(reply)
status, headers, response = reply
headers["Expires"] = CGI.rfc1123_date(11.months.from_now)
build_new_reply(status, headers, response)
end
end
end
To decrease the load on my Heroku Rails server, I am also using a free account at CloudFlare which provides a lightweight, reverse-proxy/cdn, with some decent analytics and security features.
When I get around to caching common content, this thing is really gonna scream!
You could, as I do, use jammit force to pack your assets, upload everything to s3 and define an asset host(s) in rails. This has the added advantage of keeping your slug smaller and more responsive as you can add your public directory to .slugignore .
Alternatively you'll need to work out how to make the heroku version work due to the read only file system.
You can also use a git pre-commit hook to ensure your assets are packaged prior to pushing to heroku (or any server). See https://gist.github.com/862102 for an example. You can copy that file to .git/hooks/pre-commit in your project directory.
this one is the solution
https://github.com/kylejginavan/heroku_jammit
Heroku has a read-only file system, so Jammit is unable to actually store compressed and minified CSS/JS files.
Here is a very good article on the challenge of asset packaging on heroku: http://jimmycuadra.com/posts/the-challenge-of-asset-packaging-on-heroku