Get the complete code on github.
It’s always exciting when a new major jQuery version (x.x.0) full of bug fixes, new features and performance improvements is released. But that fresh, out of the box excitement can get replaced with anxiety if you find bugs or performance issues with the latest version. This post will cover a way to include jQuery while provide a way to test pre-release versions of jQuery.
When a major version of jQuery is being developed, far too few developers actually test the beta and release-candidate (RC) versions inside of their applications. This can be challenging for those putting time and effort into a steady beta and RC release schedule, and those expecting a bullet-proof version of jQuery upon release. While there are over 6000 unit-tests for jQuery, as well as manual testing done by the core and bugs team, it’s not always enough to find new bugs or possible performance hits in user-land code. The result is a major release landing, everyone downloading and upgrading in a frenzy, and that needed testing from the community happening on a full-fledged release. Thus, the x.x.1 release is right on the tails of x.x.0. This problem is not as bad on subsequent point-releases, since they are only include bug fixes, but it still happens.
What’s the solution? Help test the latest versions, of course! This is as simple as replacing the stable version of jQuery in your application with the latest beta or RC, and making sure everything still works right - or if it doesn’t, letting the jQuery project know what broke and how.
Unfortunately, manually adding in the latest version of jQuery to your site, even in a staging environment, can be a hassle. We can improve this situation by implementing a switch that lets us use a stable version of jQuery by default, while allowing a different jQuery version to be loaded for testing just by specifying a version number in the URL.
An easy way to specify a particular version of jQuery on a page would be a query string argument, such as
jqversion=1.7.0rc1. We can use a simple regular expression to get that out of the search property of the location object (the object that holds all the information about the uri the page is currently on).
This looks for
jqversion= followed by any digits, letters, or periods. By limiting the match to only those characters, possible XSS vulnerabilities are avoided, such as someone entering
jqversion="><script src="http://hax.com/someScript.js"><\/script> in the URL. If the regular expression matches,
verMatch will be an array of the original search text and the match, e.g.,
[ 'jqversion=1.7rc2', '1.7rc2' ]. Let’s put that into a variable:
We’re using short-circuit evaluation here. First,
verMatch is evaluated. If it’s falsy, it will stop evaluating and assign that falsy value of
version. If it’s truthy (i.e., if there was a match with the regular expression) the expression will continue on and evaluate
verMatch. The resulting
version variable is either
verMatch being equal to
null (a falsy value meaning there was no match) or
verMatch, the matched version number from the URL (a truthy value). Checking for
verMatch before assuming that
verMatch exists is essential. If the regular expression didn’t match, an error would be thrown when attempting to access the 2nd element on a null object.
If a version was specified in the url, we now have that stored in the
version variable. To use that version information to make a script tag pointing to the correct file, we can use
This writes the script tag pointing to the un-minified copy of the jQuery version specified immediately after the script tag this code is currently executing in.
While having the un-minified copy of jQuery is helpful for debugging, it’s recommended to use a minified copy in production. Also, here at Bocoup, we like to use Google’s CDN since they have more servers, higher speeds and more saturation (more possibility of a cached copy). If a version is specified, the jQuery CDN with an un-minified copy should be used. If a version isn’t specified, the Google CDN with a minified copy should be used.
Now this is starting to take shape. However, making the
version variables global is unnecessary. And it would be nice to have some kind of local copy of jQuery if Google’s CDN has any issues serving the file. The multiple document.write calls don’t seem very DRY, either.
Here’s the final version that can replace the typical
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script> tag used to include jQuery on a webpage.
By default, the page will load a minified version of jQuery from the Google CDN. If that doesn’t work, it will load a local copy of jQuery. If
jqversion=, followed by the version tag, is in the URL it will attempt to download that from the jQuery CDN. For example,
jqversion=1.4.4. The whole code block is wrapped in an IIFE to keep the variable’s scope to just that function. The local jQuery fallback code goes in another script tag. Since we’re injecting a script tag using
document.write, it won’t download and load before the check for
window.jQuery runs if it’s in the same script tag.
In both code snippets, you can replace the
1.7.1 in the googleapis.com URL to whatever version you want to have on your page, such as,
1.5.2. Also, be sure to update the path pointing to your local jQuery copy in the second
You can also test the latest development copy by using
git as your version, e.g.,
jqversion=git. If you’d like to see what version of jQuery is currently loaded on a page, that is stored in the jquery property on jQuery’s prototype at
$.fn.jquery and thus as the
jquery property on any jQuery object, e.g.,
$( document ).jquery.
Follow along with the jQuery Blog to see when betas and release-candidates are released. Testing will be a piece of cake with this new jQuery include process. For example, when the 1.8.0 release-candidate is out, a url like
http://yoursite.com/?jqversion=1.8.0rc1 will let you load your site with that version of jQuery. Found a bug? Report it on the jQuery bug tracker. Want to chat with the development team? Head into #jquery-dev on irc.freenode.net. Filed a bug and already fixed it? Submit a pull request on github. Spending even a little bit of time testing your sites with the in-development copies of jQuery can help significantly in assisting the project to finding bugs before final releases are made. Happy testing!