Recently, it has become fashionable to merge all external JavaScript files of your site into one large, downloadable once and for all. This is, frankly, good - the browser does not make one hundred million requests to the server to display one page ¹ , the download speed increases, users are happy, the developers are resting.
As always, there is a fly in the barrel of honey - in the merged file in this case there is a lot of things that you could not load at the first request. ² There should have been a link to Habratopik with the appropriate discussion. Successfully lost. Most often, to combat this, it is suggested to throw out unnecessary parts with your hands ... Personally, I have the prospect of shoveling a few dozen (or even hundreds of ³ ) kilobytes of JavaScript code every time causes an acute reluctance to work - and you?
under the cut: description of the simplest algorithm for resolving dependencies between modules

Constructive suggestions

Proposal one: disassemble the framework you use into its component parts. JSON - separately, AJAX - separately, work with DOM - separately, forms - separately. After this, the task of “throwing out the unnecessary” becomes the task of “collect only the necessary”. A definite plus - the result of the assembly was less. Undoubtedly a minus - if something from the "necessary" is forgotten, everything stops working.
Proposal two: save information about dependencies between components. (Forms use the functions DOM, JSON - AJAX and so on.) At this step, forgetting something necessary becomes much more difficult, and the assembly is transformed from a fascinating puzzle "... @ # $, why everything stopped working ..." into a routine and tedious operation.
Proposal three: save information about which modules the site as a whole needs. Is AJAX used? Are there any forms? Any unusual controls?
Fourth sentence: think, and make the machine work.

Theory

From a formal point of view, after the first and second steps are completed, we have a tree of ⁴ dependencies. For example ... (do not shoot the pianist - the example is sucked from the finger)

 - dom.js
   - array.map.js
     - array.js
   - sprinf.js
 - calendar.js
   - date.js
   - mycoolcombobox.js
     - dom.js
       - array.map.js
         - array.js
       - sprinf.js
 - animated.pane.js
   - pane.js
     - dom.js
       - array.map.js
         - array.js
       - sprinf.js
   - animation.js
     - transition.js
 ... and so on ...

In the third step, we directly select the vertices that the site needs. Let it be dom.js and animated.pane.js.
Now the work of technology to get around the resulting set of trees in depth

 - array.js
 - array.map.js
 - sprinf.js
 - dom.js
 - array.js
 - array.map.js
 - sprinf.js
 - dom.js
 - pane.js
 - transition.js
 - animation.js
 - animated.pane.js

... remove duplicate items:

 - array.js
 - array.map.js
 - sprinf.js
 - dom.js
 - pane.js
 - transition.js
 - animation.js
 - animated.pane.js

and merge the relevant modules together.

Little practice

How to store information about dependencies?

Personally, I prefer to add service comments to the “modules”:

 // #REQUIRE: array.map.js
 // #REQUIRE: sprintf.js
 ....
 code

It is easy to select such tags from a text file.
Naturally, in order to get a complete dependency tree, you will have to go through all the available files - but the full tree is usually not needed.

What have we come to?

Having spent a lot of time once on forming modules and dependencies between them, we save time every time we want to reduce the amount of external file downloadable by clients. Nicely. But still, part of the problem remains - the user downloads all the JS code that is used on the site at a time, even if this code is not needed on the current page.
(To be continued...)
¹ With properly configured caching (the presence of 'Expires'), these requests will be sent only when the page is first loaded. Nevertheless, they meet on clothes.
² For example, the entire Prototype as a whole, instead of the individual functions '$' and '$$', aha.
³ You do not use the JS-framework (even if you own a bicycle of your own invention)?
⁴ Actually, not a tree, but a DAG (Directed Acyclic Graph) - I just do not know the correct Russian-language term. Oh yeah, if you had cycles in dependencies, something was broken somewhere wrong.