Universal (AMD/Node/plain browser) module

gistfile1.js

/**
 * First, better, "set exports/return" option
 */
(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) {
        //If have dependencies, get them here
        var a = require('a');

        //Return the module definition.
        return value;
    });
}(typeof define === 'function' && define.amd ? define : function (id, factory) {
    if (typeof module !== 'undefined' && module.exports) {
        //Node
        module.exports = factory(require);
    } else {
        //Create a global function. Only works if
        //the code does not have dependencies, or
        //dependencies fit the call pattern below.
        window[id] = factory(function(value) {
            return window[value];
        });
    }
}));


/**
 * 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 = value;
    });
}(typeof define === 'function' && define.amd ? define : 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 window[value];
        }, (window[id] = {}));
    }
}));

@jrburke Thanks for the quick reply, just another quick question. So I'm writing a jQuery plugin that is AMD/UMD compatible but the plugin it self has to have a dependency on jQuery. Using the boilerplate above it's hard to require jQuery assuming jQuery is not global.

How can the plugin be told to load jQuery from any relative module path?

I was thinking a UMD could have a configuration object but would you put in the source file or somewhere else?

I guess Require.js paths should work well enough.

Right, the jquery plugin should specify 'jquery' as a dependency. I suppose one problem with the UMD in that case is that the 'jquery' dependency is found at window['jQuery'] so probably need to special case that require stub for the global window case.

But in any case, the plugin should specify 'jquery' and the app loading both modules (since jquery in 1.7 will register as 'jquery' named module) using paths config as appropriate.

I don't fully understand what ['jquery'] does so I will just use ['jQuery'] and keep it up to the user to define the right path to jQuery and if it is loaded in noConflict or not

The dependency names should match the file name casing, so ideally there are no paths config and 'jquery' is just baseUrl + 'jquery.js'. Since jQuery ships as a file in a lowercase name, the dependency name is in lowercase. If you use 'jQuery' then you will need to be sure to always use a paths config or match the casing in the file name.

@jrburke @unscriptable @thomasdavis still considering whether this is a good idea, but what are your thoughts on formalizing some of the UMD work that's being worked on both here and in the other patterns project into a unified effort or repo/project?

At the moment a lot of our efforts exist in distributed gists which only a limited group of people are aware of but we have the potential to get more people actually using this stuff.

If you feel it makes more sense to just post this as an extension of the AMD wiki, that's of course cool, but I was just curious as to what the final goal / location for informing others about this work might be.

@addyosmani I'm open to publishing it somewhere else than the AMD wiki. That wiki was just convenient since a few of us already have access to it. I was thinking actually not having it on the wiki portion but as part of a doc in a repo so that changes and comments on changes could be tracked easier. I can see it may be a collection of documents -- one for each sort of sub-type (something specific to jQuery plugins for example).

So all that said, I'm open to some other place to host it. If you have a specific idea or want to set something up, I'm all game.

As far as this specific boilerplate, I am feeling positive about it sticking. I am just waiting to hear back officially from one other person in the AMD world, but initial vibe was receptive. It also will work well with some changes that may be happening for the jetpack/add-on toolkit for firefox add-ons.

@jrburke Perfect.I was thinking of something along the lines of setting up a new repo or organization for taking the UMD work further. Let me setup something this evening. I'll add everyone that's been involved in discussions so far and we can see how things might shape there.

what about this simplest approach? https://alicoding.com/write-javascript-modules-that-works-both-in-nodejs-and-browser-with-requirejs/

7 years on, and UMD to consider - are there any updates (or links for referral)?

@PandaWood Yes, here: https://github.com/umdjs/umd