So you're creating a bunch of code in an external .js file that requires jQuery and a few of its plugins, or MooTools, or perhaps some more esoteric libraries. Obviously the actual "include" is done in the host HTML page in the HEAD section as you load in each script.

But as a best practice for portability, what built-in features, or widely-adopted conventions exist within your JavaScript .js file to ensure that the next schmoe who uses your code remembers to also include those other required libraries?

I'm looking for some consensus from the developer community, so please be sure to vote for the answer that seems most common or that you are the most familiar with.

So you're creating a bunch of code in an external .js file that requires jQuery and a few of its plugins, or MooTools, or perhaps some more esoteric libraries. Obviously the actual "include" is done in the host HTML page in the HEAD section as you load in each script.

But as a best practice for portability, what built-in features, or widely-adopted conventions exist within your JavaScript .js file to ensure that the next schmoe who uses your code remembers to also include those other required libraries?

I'm looking for some consensus from the developer community, so please be sure to vote for the answer that seems most common or that you are the most familiar with.

• javascript
• dependencies
• conventions

• 1 Can't you explicitly check for your dependencies and throw exceptions if they're not satisfied? – Pointy Commented Jun 22, 2011 at 19:37
• Sure can, and probably should do. But I also want something more visible, like a "use" in Perl, an "import" in ActionScript, or a "include" or "require" in PHP. Not that I expect to discover some heretofore undisclosed JavaScript directive, but at least a documentation best practice that a lot of developers can agree on. – Tom Auger Commented Jun 23, 2011 at 13:46
• Ah. Well, yes, the lack of a "module" solution in JavaScript is something that many, many people bemoan. The future spec beyond ES5, called "Harmony", may introduce some sort of solution to this problem. – Pointy Commented Jun 23, 2011 at 13:47

4 Answers 4

jQuery UI adds the dependencies of their widgets in the file header:

/*
* jQuery UI Effects Bounce @VERSION
*
* Copyright 2011, AUTHORS.txt (http://jqueryui.com/about)
* Dual licensed under the MIT or GPL Version 2 licenses.
* http://jquery.org/license
*
* http://docs.jquery.com/UI/Effects/Bounce
*
* Depends:
* jquery.effects.core.js
*/

Now unfortunately JavaScript dependency managers are used way less than they should, but if you can make your libraries users switch to one you wouldn't have to worry about that at all:

• StealJS
• Jingo
• YUI loader
• Pyramid Dependency Manager

Checking explicitly might be a good idea, too, since you can dynamically react if certain plugins are or are not available (e.g. either throw an exception if the jQuery UI dialog hasn't been found or just degrade gracefully and show a simple modal window):

if(!$.isFunction($.fn.dialog)) {
    throw "Could not find jQueryUI dialog. Please include jQuery UI";
}

That way your script doesn't have to break entirely if an optional dependency is not met.

For the Visual Studio developers out there you may want to try blocks like these in your header

/// <reference path="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.6-vsdoc.js" />
/// <reference path="thirdparty/ba-debug.js" />
/// <reference path="thirdparty/underscore.js" />

While this doesn't resolve your dependencies, it does document them, AND it gives you intellisense in Visual Studio...

See http://msdn.microsoft.com/en-us/library/bb385682.aspx, then look for References Directives (no a name or id to link directly to, sorry...)

my js headers look like this:

////////////////////////////////////////////////////////////////////////////////
//
//  src:        www.someDomain.com/js/modules/etc
//  author:     someguy
//  date:       6-22-11
//  intent:     what is the purpose / use of this module
//  package:    prototype parent
//  requires:   jquery.1.4.js
//              fancybox
//              etc
//
////////////////////////////////////////////////////////////////////////////////

Any dependencies are then quite clear to anyone on my team, and this has proven pretty reliable. As a (hopefully) secondary measure, I will always test for those dependencies at runtime and throw up an alert should a script not be included.

I always believe that software engineers should always know, or at least be reminded, be forced to know what they are doing. They should keep the list of the dependencies by themselves and be very clear about why he/she needs them. There are not many js files to include in a page anyway.

I think it should be nice if the browsers have the jQuery and some nice plugins with them, so we do not need to inclcude them in in the page to save traffic though.