Discussions

[addyosmani]

This issue is to discuss the current patterns in the repo as well as how we would like to address the variations on the todo list. I recall that Thomas had some particular comments here about how best the library/noConflict versions should best be handled, but let's carry on the conversation here so that it's not left in gists and lost later :)

[zhikuanlin]

hi, i see "window[id]" in the umd1.js, and umd2.js,
i think using "this" is better than "window", because "window" only exists in a browser environment:

(function(host) {
// in a browser environment, host === window
})(this);

[addyosmani]

Thoughts on the above?

[zhikuanlin]

i mean "window" is a browser-specific variable, avoid using it in crossing-platform code,
new code here ("window" is instead by "host"):

/**
 * exports object based version, if need to make a
 * circular dependency or need compatibility with
 * commonjs-like environments that are not Node.
 */
(function (define) {
    //The 'id' is optional, but recommended if this is
    //a popular web library that is used mostly in
    //non-AMD/Node environments. However, if want
    //to make an anonymous module, remove the 'id'
    //below, and remove the id use in the define shim.
    define('id', function (require, exports) {
        //If have dependencies, get them here
        var a = require('a');

        //Attach properties to exports.
        exports.name = 1;
    });
}(typeof define === 'function' && define.amd ? define : function(host) {
    return function (id, factory) {
        if (typeof exports !== 'undefined') {
            //commonjs
            factory(require, exports);
        } else {
            //Create a global function. Only works if
            //the code does not have dependencies, or
            //dependencies fit the call pattern below.
            factory(function(value) {
                return host[value];
            }, (host[id] = {}));
        }
    }
}(this)));

[jfsiii]

@addyosmani or @zhikuanlin can you show a very simple example which

1. defines a module a
2. defines a module b which requires the module a from step 1

and works in Node and the browser?

I've tried all the UMD approaches I can find, but they all fail when defining a module which has dependencies.

What's the best way to deal with dependencies when defining modules to be shared between the browser and NodeJS? Is there a UMD-compatible require?

[jrburke]

@jfsiii I have been playing with the following boilerplate at the moment:

https://gist.github.com/1387943

BTW, I agree with the previous comment about avoiding window for the browser global space, the gist above passes in this for that case.

[addyosmani]

@jrburke, do you think it makes sense for us to update the repo to reflect
the gist you referenced?

I believe our last point of action with UMDs was creating a site or
resource page around them but it would be useful to track your current
progress on what you feel is the most reliable (current) pattern for use.

On Wed, Nov 23, 2011 at 5:31 AM, James Burke <
reply@reply.github.com

wrote:

@jfsiii I have been playing with the following boilerplate at the moment:

https://gist.github.com/1387943

BTW, I agree with the previous comment about avoiding window for the
browser global space, the gist above passes in this for that case.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com

[jrburke]

@addyosmani I just pushed a big set of changes to this repo along the lines of trying to update it.

Everyone, please review, particularly for accuracy.

@thomasdavis: I kept your umd3-draft.js in there, but I do not link to it in the README, since it was marked as a draft.

[addyosmani]

Thanks for the heads up @jrburke!. I'll be sure to take a look through the changes right away.

[addyosmani]

Some quick initial comments:

The patterns I've reviewed so far look very clean. Agree with the comments regarding CJS usage when working with jQuery plugins - it's very unlikely that this is something that will be done in practice, but very useful to have a pattern that covers it in the off-chance someone is looking for a reference point.

Question: Should we assume that if someone is looking at any of these formats, they already understand how AMD/CJS modules work and should be loaded? There is currently a todo item for 'usage examples' I just read but any sort of examples would certainly help people arriving at this repo.

Great work, James! Thanks for updating this.

[jrburke]

On Thu, Nov 24, 2011 at 12:13 AM, Addy Osmani
reply@reply.github.com
wrote:

Question: Should we assume that if someone is looking at any of these formats, they already understand how AMD/CJS modules work and should be loaded? There is currently a todo item for 'usage examples' I just read but any sort of examples would certainly help people arriving at this repo.

I can see expanding out the readme a bit more to explain a bit of
background and context, but I am unlikely to get back to this repo for
a bit, so you (or anyone else) should feel free to take a crack at it.

[jrburke]

FYI: I added a variant that is just AMD+web in this commit.

I think this will be useful for folks that do not need to or cannot support the node environment, or want to use a converter that will format the module for use in node/npm.

[wilmoore]

Thus far, my testing has shown that the following seems to work in all environments:
https://gist.github.com/3880415

I've taken parts from:

• https://gist.github.com/1387943
• https://github.com/chaijs/chai/blob/master/chai.js#L1-11

Works with multiple dependencies as well.

[jrburke]

Just marking this as closed, no specific code changes needed, but feel free to continue discussion in this ticket. If there are code changes that need to be done, separate tickets can be opened for them.

@wiimoore, there are a few variations on the theme that work. The key for AMD at least is to make sure the define() call looks like a top level function call and not a property/method call, so that when building happens the module ID can be inserted by the build tools. Doing a quick scan, your gist seemed to have that, so it passes on that requirement.