I have several JavaScript files in my web application which were previously loaded through <script> tags, in order of relative dependencies. Now I'm re-organizing them through require.js in order to accumulate and minify them for production.
For starters, I'd like to simply load all files into the global (window) context, without AMD encapsulation yet:
require([
'jquery'], function() {
require([
'jquery-ui'], function() {
require([
'jquery-ui.touch-punch',
// [...]
]);
});
});
The idea here is that 'jquery' defines a global (window context) jQuery variable, 'jquery-ui' sets jQuery.ui and 'jquery-ui.touch-punch' alters jQuery.ui (for better touch support).
This works well when running as is, i.e. without optimization. However, after compiling into one file and minifying using the RequireJS optimizer, the following error occurs:
Uncaught TypeError: Cannot read property 'mouse' of undefined
This happens on a line trying to access jQuery.ui.mouse.
Inside the browser console, jQuery is correctly set in the window context, but jQuery.ui is undefined.
However, manually executing require(['jquery-ui']) does set jQuery.ui as expected.
It seems like jQuery UI behaves differently after optimization, but I can't see how exactly or why. What am I doing wrong?
The Scoop
Set the dependencies between non-AMD modules using shim rather than through nested require calls (which do not in fact set dependencies). Make sure also to use wrapShim: true in the configuration you give r.js.
Explanation
One or more of the modules you are trying to load are not AMD modules, but you are not actually defining dependencies between your non-AMD modules.
When you nest require calls like you do, you are coercing the order in which some modules are loaded at run time, but this does not actually establish a dependency between modules. So this strategy works as long as the modules are not optimized but may fail after optimization.
There are only two ways to establish dependencies:
By passing an array of dependencies to a define call. This method is used by modules actually written for the AMD spec. (RequireJS also supports using the CommonJS way of requiring modules but behind the scenes, it is transformed to a define call with an array of dependencies. So it does not constitute a 3rd way.)
By setting a shim which list dependencies. This method is for non-AMD modules.
If you don't set a shim, then the optimizer is free to order the non-AMD modules in whichever order it wants. jquery-ui.touch-punch could appear before jquery-ui and jquery in the optimized file, because there's no reason it shouldn't, and then you'd run into trouble. If you look at the code of this plugin, you see that it is not AMD-aware. It just expects jQuery and jQuery UI to be present and will fail if they are not present.
When you do set a shim, then you coerce the order of the non-AMD modules in the optimized file.
You need wrapShim because the jquery-ui.touch-punch when using an AMD-aware version of jQuery UI. Otherwise, jQuery UI's factory won't be run before the plugin needs it.
I really like AMD-like syntax for modules management in js. Now i'm trying to figure out how can I use require.js with brunch.
This is what I want to achieve:
All vendor code should be concatenated in one file.
Exported vendor symbols should be available in global scope(since
some 3rd-party code EXCPECT to find it there).
I want to use require.js or Almod for module management.
The problem is if I load require.js some of vendor scripts are trying to define anonymous module. Here is a code snipped from Backbone for reference:
if (typeof define === 'function' && define.amd) {
define(['underscore', 'jquery', 'exports'], function(_, $, exports) {
//...
});
}
As a result, require.js complains about anonymous module definition.
This is why wrapping of vendor code is disabled by default in Brunch. Many vendor scripts have UMD or their own way of exposing their API that is incompatible with generic module wrapping, but they will work out of the box with your AMD structure if left alone.
What you may want to do is organize your vendor scripts into separate directories by the ones that need wrapping by Brunch and the ones that don't; something like the vendor and vendor-wrapped. Using default conventions settings, Brunch will wrap the scripts in vendor-wrapped and not the ones in vendor. Then you can concatenate them both together (based on your prior question's example):
joinTo:
'js/vendor.js': /^vendor(-wrapped)?[\\/](?!mocha|chai|sinon|sinon-chai)/
There is still the possibility that you'll encounter some vendor scripts that are structured in such a way as to just be incompatible with AMD, even when wrapped, and in those cases your choices are to either not use those libs, work with the authors to get them updated, or maintain your own modifications to make them compatible with your project.
I am trying to shim certain modules for usage with almond like so:
<script>
requirejs.config({
shim: {
'jQuery': { exports: 'jQuery' },
//etc.
</script>
as certain scripts will already be included. However, this code:
require(['jQuery', function($) {
});
results in "undefined missing jQuery". If I shim jQuery like this:
define('jQuery', function() {
return jQuery;
});
it works.
I am not building my JS at all, just dropping almond.js into an existing web software so I can develop my new components with AMD. I would like to shim existing globals for my new modules.
I am guessing shims are only resolved on build and that the build does exactly what I am doing above, is that correct?
The name for jQuery is hard-coded to "jquery". If you deviate from this you'll run into trouble. But that's not your only problem.
Using shim is not the same as calling define with a module name. When you use shim like you do in your question you tell the loader that there exist a module with the name jQuery and that once that module is loaded, RequireJS should return as a module value the value of the variable jQuery. The emphasized text is important: the loader will fetch and load a module named jQuery.
The define you show in your question would usually be placed together with the call to require.config, either just before it or just after it. This declares a module named jQuery. Because the module is already there, when the loader needs to get this module, there is nothing to fetch. This is an important difference when it comes to Almond.
Almond has restrictions, one of them is:
optimize all the modules into one file -- no dynamic code loading.
(Emphasis added.) Using the terms I've used in this answer this means "no fetching". When you use your define call, you are fine. When you use the shim, then unless you optimized your modules into one file, the loader has to try fetching the module. Almond cannot do that.
I am writing a Javascript application that is supposed to be hosted on various sites. The application itself uses jQuery and jQuery UI. I am aware of jQuery.noConflict(true) trick and using it currently so not to pollute the global space. My aim is to always keep jQuery and any of its plugins local to my application so as not to conflict with anything on the hosting site. It should be possible for the hosting site to load its own jQuery (maybe different version) and add some plugins.
Now, I would like to structure the app as an AMD module. It is OK with me to require from the hosting site to use an AMD loader (require.js, curl, etc.) but I wouldn't like to require any particular one - just anything conforming to AMD API (yep, I know it's not 100% ready yet).
Is it at all possible? Can I do it in an interoperable way, so that the hosting site can use e.g. either requirejs, curl or Dojo AMD loader?
For example, with this:
define(['jquery'], function($) {
var myLocaljQuery = $.noConflict(true);
... my app module implementation here ...
});
how can I specify the path for jQuery that my application wants to use? As far as I understand, I cannot do anything like this:
require.config({
paths: {
'jquery' : 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min'
}
});
define(['require'], function(require) {
require(['jquery'], function($) {
var myLocaljQuery = $.noConflict(true);
... my app module implementation here ...
});
});
because the first require is a global object and this is specific to requirejs.
After doing some more research, I think it is not feasible at the moment. At least for one thing - the module ids are global within AMD context, so I cannot simply use "jquery" or "jquery-ui" module IDs in my application and be sure that there won't be any conflict when someone hosts my application and wants to use jQuery (potentially other version) through AMD too. See for example here:
curl.js does not prevent conflicts with third-party scripts that may load other versions of jQuery as an AMD module.
As far as I understand, AMD is aimed at modularizing stuff within your own app. It doesn't have much support for integration with third-party apps, at least not when you want to do some encapsulation to avoid conflicts.
Let's assume this is my config.js or main.js:
require.config({
// paths are analogous to old-school <script> tags, in order to reference js scripts
paths: {
jquery: "libs/jquery-1.7.2.min",
underscore: "libs/underscore-min",
backbone: "libs/backbone-min",
jquerymobile: "libs/jquery.mobile-1.1.0.min",
jquerymobilerouter: "libs/jquery.mobile.router.min"
},
// configure dependencies and export value aliases for old-school js scripts
shim: {
jquery: ["require"],
underscore: {
deps: ["jquery"],
exports: "_"
},
backbone: {
deps: ["underscore", "jquery"],
exports: "Backbone"
},
jquerymobilerouter: ["jquery", "backbone", "underscore"],
jquerymobile: ["jquery", "jquerymobilerouter", "backbone", "underscore"]
}
});
require(["jquery", "backbone", "underscore", "app/app.min", "jquerymobilerouter", "jquerymobile"], function ($, Backbone, _, App) {
console.log($);
console.log(Backbone);
console.log(_);
$("body").fadeIn(function () {
App.init();
});
});
If I understand correctly, the paths config option allows you to reference scripts, a-la the <script> tag within HTML. Assuming this is the case, do I still need to alias scripts like jQuery with a $ or underscore with a _ in my actual require statement below? It seems strange that I'd have to, given that if you reference jQuery with a standard <script> tag, $ can be used throughout your script automatically. Shouldn't it be the same using the paths?
I'm new to the shim config option, which I understand has replaced the deprecated order! plugin. What does the exports property actually DO? It doesn't seem to create an alias for a script; for example, if I set the exports for underscore to "whatever", and then try to console.log(whatever), it's undefined. So what's the point?
How would scripts like jQuery be properly used "globally?" That is, what's the proper way to be able to use the $ alias within my App.js module, or any other module in my "app" folder? Do I have to require jQuery within every individual module and alias $ every single time? Or is the way I've done it here the proper way?
I'd greatly appreciate any other criticisms of this particular script as well; the documentation for Require.js, in my opinion, leaves much to be desired; things I'd really like to know more about seem to get glossed over and leave me scratching my head.
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
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)
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 _
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.
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.
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
} );