What does r.js really do?

Question

I'm trying to understand the benefits of the popular r.js.

It seems to...

• concatenate a list of manually selected JavaScript files
• uglify/minimize that combined code
• do some similar stuff for CSS files (combine them)

Also, (what it makes it different from generic combine/minify tools) it seems to...

• convert Node-style require() modules to AMD style modules
• name anonymous modules (eg. define(['dependency'], function(){...})
• offer some support for loader plugins, e.g. inline CSS files

It does not seem to...

• analyze and automatically resolve dependencies found in files (like, include file foo.js into the package just because r.js finds a define(["foo"], ...)

Is this correct, or did I miss something?

Apron

Uh, was my edit incorrect and you really meant that it should "include file foo.js into the package just because r.js finds a define(["foo"], ...)"? If the code is already there (foo is defined), I don't see why you would want it to load the foo.js file. – Chaldean

RequireJS/Optimization: "[r.js] Combines related scripts together into build layers and minifies them". The dependency graph itself is still resolved at run-time, all the modules have simply been shoved together and so do not require separate resource fetches. – Austenite

@Bergi: Don't know about your edit, but yes, I want to make sure that it's correct that r.js does not automatically resolve any dependencies. I'm not saying it should do so. It just appears to me that r.js does some heavy JavaScript parsing/processing and want to make sure I understand all steps in that process. – Apron

@user2864740: so, for modules that are already AMD-style, r.js does not do any special processing that can't be done by a classic combiner/minifier? (no criticism intended) – Apron

@UdoG I mean: Normal module-per-file dependencies will be included, pretty much unless excluded, but the object graphs/load-order won't be. – Austenite

@UdoG how would u handle any non amd dependencies though without r.js? – Barbiebarbieri

Answer 1

You are wrong, because r.js does automatically resolve dependencies. If you have a main.js file with this:

define(["foo"], function (foo) {
});

Then if you ask r.js to create produce an optimized module out of main.js, it will include the code for module foo into the build.

Some caveats:

1. It is possible to tell r.js to exclude modules. So if a module you think should be in an optimized bundle is absent, it may be that it has been excluded. (You know how you are using r.js but if you use a bundle produced by someone else and you wonder, then this may be the answer: they specifically excluded a dependency from the build.)

2. r.js does not find nested dependencies unless you tell it to. For instance:

   define(function () {
       require(["foo"], function (foo) {
       });
   });
   

   r.js won't find that foo is required unless you set findNestedDepencencies to true in your build config.

3. r.js can find only dependencies that are specified in the form of a list of string placed as a literal in the location where the require and define calls expect dependencies. So if you do:

   define(function () {
       var deps = ["foo"];
       require(deps, function (foo) {
       });
   });
   

   Then r.js won't know that foo is a dependency, because in require(deps, ... your dependencies appear as a symbol reference, not as a list of strings. You would have to specify foo as a dependency manually in the build configuration. There's no flag to turn on to make r.js find these cases.

Cholesterol