I'm starting a new project in Rails, and it looks like the application.js manifest file is doing something funny with the javascripts that I reference - does it cache those files as part of the asset pipeline?
Here's what happened. I added a javascript file named jquery.autoresize.js to the vendor/assets/javascripts folder, and then referenced the file in the application.js manifest like this:
//= require jquery.autoresize.js
Then I started up the rails server. But after navigating around in my app, I realized that I had accidentally added the wrong version of the jquery.autoresize.js file. So, I deleted that file and then added the correct version to the vendor/assets/javascripts folder. But, to my horror, when I reloaded the page, it is still loading the old javascript file.
I tried emptying my browser cache, then exiting and restarting the Rails server, but to no avail. I hacked a solution together by simply renaming my javascript file and referencing the new name, which worked fine. But there has got to be a better solution to this.
Does the new asset pipeline cache the files you reference somehow? If so, how can I clear that cache? Thanks for any help!
I'm assuming we're talking about the production environment.
When you change any of your javascripts or stylesheets in the production environment, you need to run rake assets:precompile; this task compiles and compresses the various .js and .css files and creates the application.js and application.css files that is loaded by your views.
It's possible that if you replaced jquery.autoresize.js with a version with an older timestamp, the precompile step might skip it, thinking the compiled version is up-to-date. You can avoid that by running rake assets:clean first, forcing it to rebuild everything in the public/assets directory from scratch.
Also try rake assets:clobber. This will totally reset everything and delete all compiled assets. In addition, I often need to set the environment before pushing to production by going: RAILS_ENV=production rake assets:precompile.
Rails automatically clears the cache for an individual file every time that the contents are edited. To clear the cache for a single file, simply open the file, edit a line of code, and re-save it. Rails will clear the cache for that file, and the browser will load the new file the next time the page is loaded.
The reason jquery.autoresize.js was using the old cached version of the file was because the old version was deleted and then the new version was copied and pasted with the same name into the same folder. Because the file itself was never edited, Rails continued to use the old file that was cached.
This is because the asset pipeline uses fingerprinting for the cache.
Fingerprinting is a technique that makes the name of a file dependent
on the contents of the file. When the file contents change, the
filename is also changed. For content that is static or infrequently
changed, this provides an easy way to tell whether two versions of a
file are identical, even across different servers or deployment dates.
When a filename is unique and based on its content, HTTP headers can
be set to encourage caches everywhere (whether at CDNs, at ISPs, in
networking equipment, or in web browsers) to keep their own copy of
the content. When the content is updated, the fingerprint will change.
This will cause the remote clients to request a new copy of the
content. This is generally known as cache busting.
The technique that Rails uses for fingerprinting is to insert a hash
of the content into the name, usually at the end. For example a CSS
file global.css could be renamed with an MD5 digest of its contents:
global-908e25f4bf641868d8683022a5b62f54.css
So, if you delete a file you're referencing in the manifest, and then copy in a new file with the same name, the cache busting never occurs. When you edit the file, the fingerprinting kicks in, and a new hash is generated for the file name. This busts the cache for that file.
For the full story, see What is Fingerprinting and Why Should I Care?.
rake tmp:clear did the trick for me, I'm using less-rails.
I use config.assets.version = '1.01019' in my application.rb to bust the entire cache. When I want to push a complete new version, I increment the version and that does the trick. This takes care of those edge cases where Rails does not recompile as asset for whatever reason.
Related
I am noticing that Aurelia is building to the scripts directory in my CLI project. Is it safe to add this directory to .gitignore, or is there some reason to track changes to 'scripts' in Git?
You can safely add scripts to the .gitignore file.
Aurelia CLI uses the scripts folder to store the generated scripts (vendor-bundle.js and app-bundle.js).
vendor-bundle.js is for libraries (e.g. aurelia-binding, bluebird and jquery).
app-bundle.js is for all your HTML, CSS and JS files from the src folder combined in one JS file.
Because these files are renewed every time you run au run or au bundle, there is no need for them to be in version control.
Depending on what functions the scripts have, you might want to leave them in the repo.
E.g.: you add a new member to your team, and said scripts might be required for your project to work. In which case, if they're not in the repo, he will bother one of you to transfer them to his computer.
Edit: If the scripts are automatically generated every time you build the project, or if they are downloaded via a packet-manager, then there is no need to leave them in the repository.
If this is the case, it's a safe bet you can add the folder to the .gitignore. If this is not the case, then it might be better to leave them in the repository.
This all depends on your project, where you are putting your scripts and how the frameworks work.
I have a MVC web application and I have deployed it.
After that I have modified a .js file which alone needs to be moved to production. I did moved the .js file and it doesn't take the latest changes js file in production, instead it use only the previous one during the deployment.
My question is
1. Is the .js files are also get complied along with the .dll files?
2. Is there a way to move the modified .js file alone to the production without moving the complied code?
That may be because of client browser caching. please check to remove caching.
So, just CTR + Shift + Delete and clear cached data.
Is the .js files are also get complied along with the .dll files
No, always calls file will complied.
Is there a way to move the modified .js
Simple way is to replace your latest js file with old js file
production without moving the complied code?
No, need to deploy whole code all the times.
Moreover, you can go though a document: Determining What Files Need to Be Deployed
And this: https://stackoverflow.com/a/9322505
I am using JSPM and SystemJS for loading and bundling front end code. What I wonder is that is there any need to version bundled files, if yes, how to do that because I couldn't find anything about versioning bundles.
You need to add some kind of "version" to the bundles so that if there are some changes on a bundle, the client will get the latest bundle - otherwise the client might get an older version because of browser caching or some other cache.
One possible way to do this is to add an hash to the name of the bundle so that if there are some changes, the hash will be different. However, for that to work, you will need to somehow map the name of the generated bundles when loading the page. One thing I usually do is to save a json file with the bundles names.
I may just be doing something wrong but all of my javascript files as well as my css files are each individually available. This would be perfect except asset pipeline also adds my applicaion.js which is making my javascript crash. Is there a way that I can tell rails not to load all the individual files, I want JUST the application.js/css files.
As you can see here, the search and sort bars are shown twice because the javascript is trying to run twice. Anyone else deal with this? I have seen a couple other people ask this question and have yet to see a good answer.
IIRC this is caused by you having pre-compiled assets in public/assets, but having config.assets.compile set to true in the config for your current environment.
Normally if you're compiling assets on each request application.css and .js will only contain code that you have specifically entered into those files in app/assets, whereas if the assets have been pre-compiled (and are in public/assets) you'll see all your css and javascript in those files.
To fix this issue rm -rf public/assets and you should be good to go.
I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).