How do you keep your Javascript libraries updated to the latest versions in a large web project?

When working on a larger web project (say 20 plus pages), how do you keep your Javascript libraries updated to the latest versions? I specifically use jQquery a lot. It seems like everytime I look, there is a new version out. I include the jQuery library on all my pages and it's a pain to have to update it on each page. What do oth开发者_高级运维er people do? I'm sure a big answer will be to use a framework with a single front controller. And I have considered that, but I'm not ready to go that route yet.

We don't.

It might automatically break things when an update is not backwards compatible. We check the mailing lists and forums regularly too check if new versions have come out, read the changelog and/or codediff, and check our plugins for compatibility. We usually clone the server to a goldencoat, test the new version there and see if anything breaks.

If the advantages outweigh the effort needed for the update, we do so, but only after enough time has passed and the version's initial bugs have been found and solved by the community.

You can always use the latest jQuery with this url:

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

Of course you have to be careful as it may break things (especially if there's a major version change).

Here is an option for you that does not involve a framework or server side includes

All pages load your own bootloader library.

So let's assume you have a boorloader.js file and all html files include it. Inside that one file you can insert the following code at the top.

var jq = document.createElement('script');
jq.src = "https://ajax.googleapis.com/ajax/libs/jquery/1.6.0/jquery.min.js";
var head = document.getElementsByTagName('head');
head[0].appendChild(jq);

you can abstract much of this to support a lot of different data points but the end result is you asynchronously inject the jQuery library from one file. Update it once and all your HTML is updated too.

Some form of template or include system, of which there are many.

Big frameworks tend to come with template systems, but you don't have to use one. You don't even need server side programming if you preprocess.

I generally just use an "opaque" target to a resource that I control -- e.g. "jquery.js". This, however has several disadvantages:

1. Can't rely on exact version from CDN (must be a controlled resource). For a local Javascript resource this isn't an issue anyway, but it does affect libraries with well-known CDN URLs.
2. All files must use the same version at all times. (e.g. "jquery.js" is "jquery-1.4.1.js"). This has not been a problem for the projects I work on, but it might be an issue as for larger projects.
3. Removal of some self-documentation of version number.

The problems mentioned can be mitigated, but not eliminated, with using a semi-opaque resource, such as "jquery-1.4.js" (note missing revision/bug-fix version; may refer to 1.4.0 or 1.4.1, but not 1.5.x).

Happy coding.

• Use a common server-side include that will point to the version you want

or

• Point to a local url which you then make resolve to the version you want

Generally speaking, it's not good to update libs with no reason, since the old one does what you want. But generally speaking it's good to wrap interactions with external systems so that you can centrally control them.

It's typically considered to be a bad idea to automatically update frameworks or use a front loader. Basically it means that a third party has a degree of control over your site. If they make a lot of breaking changes in the library, they will automatically get published to your site and now the site that you worked so hard on is broken.

I prefer to put things like JS and CSS in an include or a MasterPage if I'm working in .NET.