I have compiled assets using following command in rails 3.2 for production purpose.
RAILS_ENV=production bundle exec rake assets:precompile
After running above command an assets a folder is created under public. Now I want to removed non-compile assets folder because it is huge. But I have need answers to following questions.
Do I need the assets folder that contains non-compiled assets ?
If yes then what is purpose of having a non-compiled assets folder ?
I will appreciate your help.
Yes, keep them.
The purpose is that when they are taken from assets to public they are usually minified and combined, greatly saving space and helping to reduce download time for end users when using the site. But when you need to make changes, use the originals in assets.
In development mode (local, on your box), the assets version is used and is useful in traces while developing/debugging as they point to the actual source code lines in question and have the original (usually longer and meaningful) variable names.
Most likely you will need to make changes to one of your assets in app/assets in the future.
app/assets has the original source files with original formatting and these are the files you should change.
Theoretically you could delete the source files in app/assets, but then you won't be able to change anything and re-compile with those changes.
Related
The Rails guide here says
"Any assets under public will be served as static files by the
application or web server when config.serve_static_files is set to
true. You should use app/assets for files that must undergo some
pre-processing before they are served."
I'm using Rails 4.2.4. There is no public/assets folder. This leaves me wondering a few things:
What is meant by "use app/assets for files that must undergo some pre-processing before they are served?"
What is meant by pre-processing?
How is a static asset different from other assets, and what are the performance benefits of using one pipeline over the other?
Do I even need to worry about this if 4.2.4 has no public/assets folder?
Assets like javascript/css etc. need to be pre-processed - eg. minified, hashed for cache busting, passed through transpilers (like coffeescript) etc. Such assets should be kept in app/assets folder.
I believe 1 already answers that.
Passing each asset through transpilers/minifiers etc. as described in 1 during production will be very expensive and wasteful - because these assets don't change dynamically we can just do them once during pre-compilation and let static file server or cdn handle their delivery.
When you precompile your assets in deployment, the compiled files will be generated into the public/assets folder.
I recommend reading this article, which explains asset pipeline in much detail.
Recently, on my latest deploy to Heroku, I got a warning advising not to use AssetSync.
remote: ###### WARNING:
remote: You are using the `asset_sync` gem.
remote: See https://devcenter.heroku.com/articles/please-do-not-use-asset-sync for more information.
The original problem we were trying to solve by using AssetSync was that we were getting a huge slug size caused by the large assets in our application. Out of the 300MB that Heroku allows us, we were probably using close to 230MB - even though our git repo is only around 80MB.
We solved this by using AssetSync to synchronise all our compiled assets to a S3 bucket to be served through Cloudfront. After AssetSync runs, we have a hook that deletes all the precompiled assets to reduce the slug size. Basically, the workflow during slug compilation looked like this:
Let Heroku precompile the assets
AssetSync syncs all compiled assets to S3
All local copies of the compiled assets are deleted
The linked article argues a few points on why it's bad and what to use instead.
Using Asset Sync can cause failures. It is difficult to debug,
unnecessary, and adds extra complexity. Don’t use it. Instead, use a
CDN.
[...]
You should now use a CDN instead. Rather than
copying your assets over to S3 after they are precompiled, the CDN
grabs them from your website. Here are some reasons why that’s better.
Canonical assets
[...] It allows you to have single, authoritative places where you
store information. If you need to change that information, you only
need to change it in one place. [...] What happens if someone has a
failed deploy after assets get synced? What if someone modifies a file
in the S3 bucket? Instead of fixing one copy of assets, now you must
fix two.
Deploy determinism
If you’re debugging inside of a dyno with heroku run bash and you run
rake assets:precompile this doesn’t just modify your local copy. It
actually modifies the copy on S3 as well. [...] The sync part of
asset_sync can also fail if there’s a glitch in the network. What if
you only write part of a file, or only half of your assets are synced?
These things happen.
Although I agree with their points, the question remains: what's the recommended way to deploy a Heroku application that becomes huge when precompiled assets are stored in the slug?
The question is which assets files are making the slug huge?
By default, the Rails assets pipeline should only be used for small and limited internal assets (like JS, CSS, some logos, etc.).
It's not a great idea to store a huge amount of external or big files as Rails assets for many reasons aside the pipeline (like it's making your Git directory big in size too).
What's considered an "asset" in the Ruby on Rails universe?
Are user generated files, such as images uploaded by the user, considered assets? Where should they be stored in the standard file structure of a Rails project? Should they be kept clear of any asset related directories like:
app/assets
lib/assets
public/assets
Relevant: The Asset Pipeline
Generally asset is anything that browser loads after it gets the HTML page. Meaning javascript, css and any images. But as you pointed out there are two different image types in a rails project.
1) the images related to your css and layout design, those go under the app/assets/images
2) the images that your users upload, those normally go into the public/system or public/uploads folder depending on what you use to receive the uploads
The lib/assets (or sometimes vendor/assets) is where you supposed to place js/css/images related to your front-end design and provided by third party libs. Say if you want to pull in some css or a js framework, that were you should place it.
And finally public/assets is where rails will compile your layout assets from the app/assets and vendor/assets folders when you run rake assets:precompile task for production.
To have it short, your design stuff goes to app/assets, and the user uploads go into public/system
User-uploaded files are not part of assets, and should definitely be kept clear of asset-related folders. You should put them somewhere in your public directory. I put mine in public/uploads, which is a common convention. And then you should ignore those files in git (or whatever VCS you're using).
Assets are basically: javascript, stylesheets, fonts, and images which are part of the site design itself, not part of the user-uploaded content.
I am trying to figure out how to get boostrap-sass working in production mode. I am using apache to reverse proxy to either webrick or puma, but serve the static assets in public/assets directly. When I precompile assets, the bootstrap css gets included into the application-(hash).css and it works correctly.
However the compiled css references an image file (glyphicons-halfling.png) without appending the hash of the file contents. The image file is included in public/assets directory, and it is possible to browse to it by putting the correct filename in the address bar, but the filename in the css does not match it. I have created a simple demo app that demonstrates this problem, code is on my github page
The glyphicon filename is glyphicons-halflings-c806376f05e4ccabe2c5315a8e95667c.png
[EDIT]
Would still like an answer to this question, but i've just renamed the offending files to remove the hash. Since these files are unlikely to change frequently then this should work fine
Think I have it cracked, when you run rake assets:precompile, it seems that you must prefix it with RAILS_ENV=production in order for it to work properly in production mode (I guess that kind of makes sense). If you don't, some of your assets will get precompiled, but the helper methods will not generate the correct paths.
tl:dr, RAILS_ENV=production rake assets:precompile
After I deployed my upgraded Rails 2.3.x -> 3.1 (rc4) app to our test environment this afternoon, all of our stylesheets and JavaScript files were returning 404 errors. We had added the rake assets:precompile task to our post-deploy script and it took a while to determine why the assets folder didn't have the pre-compiled files we expected.
In the end, the files weren't being compiled because apparently only application.css and application.js (+ non JS/CSS files) are processed by default.
We needed to change the following configuration value as follows:
config.assets.precompile += %w( *.js *.css )
Question: why isn't this the default?
I would have expected that anything that wasn't necessary to process as a manifest file would just get copied into public/assets. Much of what I've read on the asset pipeline is essentially "stick your assets in app/assets, configure the manifest files, and it should just work". Since the assets:precompile task didn't spit out any information about what it was doing, it took a while to determine that it just wasn't looking at the files we thought it would.
Is there any reason why this would not be a good value for the precompile configuration?
Thanks!
The idea is to have all your JavaScript and CSS always loaded in one shot, rather than loading bits and pieces as you move along. That way you always have the 'world' loaded and ready to work with, rather than having to include a whole bunch of individual files here and there.
It's a bit of a larger 'up front' load, but then the browser should keep loading all the javascript from cache. So the perceived speed of the site should speed up due to having everything cached and ready to go after the first request.
This was a controversial decision to include for Rails, but so is including CoffeeScript by default. Rails has always been an opinionated framework that way.
the new sprockets-based pipeline compiles all the files in /asssets/stylesheets and /assets/javascripts get compiled into application.css and application.js, respectively, by default.
In your views, you only need to link the application files, sprockets handles the rest.
Update:
Well, you don't have to make it all into just one file... You could have an shared.js, secure.js and public.js and have them each include the parts they need...
Think of them not as javascript files, but manifest files that establish groups of javascript files which you can then include as a group with a single javascript_include_tag. While the default is to include everything in the folder into a single file, you can be always pick and choose what to include, and what not.
The 'precompile' task simply runs those manifest files and compiles the multiple files into one, while pre-processing and sass or coffee script it runs across.