Require.js is hurting my brain. Some fundamental questions about the way it loads scripts/modules

Question

Let\'s assume this is my config.js or main.js:

require.config({
    // paths are analogous to old-school 

        

Answer 1

Just to clear up any confusion around exports, it's assumed that any shim library attaches a property to the global context (window or root), or modifies an already-existing global property (e.g. a jQuery plugin). When requireJS gets the command to load a shimmed dependency, it examines the global context for a property matching the exports value of that shim config, and if it finds it, returns it as the value of that module. If it doesn't find it, then it loads the associated script, waits for it to execute, then finds the global symbol and returns it.

An important fact to remember is that unless the shim config contains an exports value, any init method on that config will NOT be executed. The dependency loader must locate a value for the module (which is what exports specifies) before that module can be initialized, which is why the property is required if there is a shim init for that module.

update: I also need to point out that if the module in question calls define anywhere, any shim config you have for that module will be ignored. This actually caused me some headaches because I wanted to use the shim config to call jQuery's jQuery.noConflict(true) method to un-globify jQuery and keep it scoped to just the modules that require it, but couldn't manage to get it working. (See update at bottom for info on how to easily do this using map config instead of shim config.)

update 2: A recent question on the requireJS google group made me realize that my explanation might be slightly misleading, so I'd like to clarify. RequireJS will only re-use a shimmed dependency if it was loaded via requireJS at least once. That is to say, if you simply have a <script> tag on the hosting page (say, for example, underscore), like this:

<script src='lib/underscore.js'></script>
<script src='lib/require.js' data-main='main.js'></script>

...and you have something like this in your requireJS config:

paths: {
    'underscore': 'lib/underscore'
},
shim: {
    'underscore': {
        exports: '_'
    }
}

Then the first time you do define(['underscore'], function (_) {}); or var _ = require('underscore');, RequireJS will re-load the underscore library rather than re-using the previously defined window._, because as far as requireJS knows, you never loaded underscore before. Sure, it can check to see if _ is already defined on the root scope, but it has no way of verifying that the _ that's already there is the same as the one defined in your paths config. For example, both prototype and jquery assign themselves to window.$ by default, and if requireJS assumes that 'window.$' is jQuery when it is in fact prototype, you're going to be in a bad situation.

All of that means that if you mix-and-match script loading styles like that, your page will wind up with something like this:

 <script src='lib/underscore.js'></script>
 <script src='lib/require.js' data-main='main.js'></script>
 <script src='lib/underscore.js'></script>

Where the second underscore instance is the one loaded by requireJS.

Basically, a library has to be loaded via requireJS for requireJS to have knowledge of it. However, the next time you require underscore, requireJS will go "hey, I already loaded that, so just hand back whatever the exports value is and don't worry about loading another script."

This means you have two real options. One is what I would consider an anti-pattern: simply don't use requireJS to express dependencies for global scripts. That is, as long as a library attaches a global to the root context, you'll be able to access it, event if that dependency isn't explicitly required. You can see why this is an anti-pattern - you've basically just eliminated most of the advantages to using an AMD loader (explicit dependency listing and portability).

The other, better option is using requireJS to load everything, to the degree that the only actual script tag you should create yourself is the one that initially loads requireJS. You can use shims, but 95% of the time it's really not that difficult to add an AMD wrapper to the script instead. It might take a little more work to convert all of your non-AMD libraries to be AMD compatible, but once you've done one or two it gets a lot easier - I can take any generic jQuery plugin and convert it to an AMD module in less than a minute. It's usually just a matter of adding

define(['jquery'], function (jQuery) {

at the top, and

    return jQuery;
});

at the bottom. The reason I have 'jquery' mapping to jQuery rather than $ is that I've noticed most plugins these days are wrapped in a closure like this:

(function ($) {
    // plugin code here
})(jQuery);

And it's a good idea to pay attention to the intended scope. You can certainly map 'jquery' to $ directly though, assuming the plugin isn't expecting to find jQuery instead of $. That's just the basic AMD wrapper - more complex ones generally try to detect what kind of loader is being used (commonJS vs AMD vs regular ol' globals) and use a different loading method depending on the result. You can find examples of this pretty easily with a few seconds on google.

Update: The workaround I used to support using jQuery.noConflict(true) with RequireJS worked, but it required a very small modification to the jQuery source, and I have since figured out a much better way to accomplish the same thing without modifying jQuery. Luckily enough, so has James Burke, the author of RequireJS, who has added it to the RequireJS documentation: http://requirejs.org/docs/jquery.html#noconflictmap

Answer 2

1. Paths tell require.js where to look when you require that dependency.

   For example i have things configured like this:

   "paths": { 
       "jquery": "require_jquery"
   },
   "shim": {
       "jquery-cookie"  : ["jquery"],
       "bootstrap-tab"  : ["jquery"],
       "bootstrap-modal": ["jquery"],
       "bootstrap-alert": ["jquery"]
   },
   

   this means that every time in a module I do

   define( ['jquery']
   

   requirejs loads the file require_jquery from the main path instead of trying to load jquery.js. In your case it would load the jQuery source file, which would then be globally available. I personally don't like that approach and for that reason in the require_jquery.js file I do:

   define( ["jquery_1.7.2"], function() {
       // Raw jQuery does not return anything, so return it explicitly here.
       return jQuery.noConflict( true );
   } );
   

   which means that jQuery will be defined only inside my modules. (This is because i write Wordpress plugins and so I can include my own version of jQuery without touching the outside version)

2. Exports (reading from the docs simply should be the name of the module you are using so that it can be detected if loading went correctly. Here is explained. So if you want to set an export for underscore it should be _

3. jQuery should be global as I explained, if you simply import it the file is executed and jQuery is global

EDIT - to answer the comments.

1. yes i mean that, you must export $ or jQuery for jQuery and _ for backbone. From what i got from the docs this is needed only in some edge cases and would not be necessary for libraries that declare themselves in the global namespace as jQuery.

   I think that requirejs needs them when it has to fallback from loading jQuery from a CDN. i think that requirejs first tries to load jQuery from the CDN, then makes a check to verify that it was loaded correctly by checking that the "exported" variable exists, and if it doesn't it loads it form the local filesystem (if you had configured fallbacks, of course). This is something that it's needed when requirejs can't see a 404 coming back.

2. jQuery is globally available because it's declared global. If you simply load and execute the jQuery script, you will end up with two globals, $ and jQuery (or you can do as i did and avoid that). Inside the define() function you can alias jQuery to be whatever you want.

   define( [ 'jquery' ], function( jq ) {
       // jq is jquery inside this function. if you declared it 
       // globally it will be also available as $ and jQuery
   } );