possible jquery plugin boilerplate

basic.js

// Basic approach. Does not try to register in
// a CommonJS environment since jQuery is not likely
// to run in those environments. See next file
// if you want to opt in to CommonJS too.

(function(factory) {
  if (typeof define === 'function' && define.amd) {
    // AMD. Register as an anonymous module. 
    define(['jquery'], factory);
  } else {
    // Browser globals
    factory(jQuery);
  }
}(function($) {
  $.fn.myPlugin = function () {};
}));

includecommonjs.js

// Includes registering in a CommonJS environment,
// but it is unlikely jQuery will run in a CommonJS
// environment. See other file if you do not want
// optional CommonJS registration.

(function(factory) {
  if (typeof exports === 'object') {
    // Node/CommonJS
    factory(require('jquery'));
  } else if (typeof define === 'function' && define.amd) {
    // AMD. Register as an anonymous module. 
    define(['jquery'], factory);
  } else {
    // Browser globals
    factory(jQuery);
  }
}(function($) {
  $.fn.myPlugin = function () {};
}));

@Zoramite

But the example from this gist seems a little more concise which I like.

Agreed that it is more concise. Mine is different (but related) in that it addresses the needs of more complex plugins. Ones that require larger APIs and can maintain separate states for each collection they're called on in a page.

As for the ! that is an interesting way of executing the function

It's become quite popular, but I've adopted it due to its readability. Like an opening paren, but more so, it signifies that the function will be immediately executed. Ending any function with }() already does a good job of signifying immediate execution and using an extra paren becomes visually redundant.

I hadn't actually seen that used in an of the JS code I have seen. :)

I first saw it used in Qwery.js.

Looking at Qwery again though, I see they have reorganized it into the same pattern as above. Looks a lot more readable than I'd expected. It visually separates the exporting business from the plugin business much better than mine. I've updated my gist to the above pattern. I guess I just needed to see an example with a lot more code to be persuaded :)

@jrburke I have seen the light :)

@jrburke, I tried to change the names of the modules to match the filename and that didn't change anything. I didn't try to add it to the paths. When I made it into an anonymous module it worked as expected. Seems kind of strange that having it as a named module would cause the dependency to fail, even when it matches the name of the file.

I just added a version that does not do optional CommonJS registration, since jQuery is unlikely to run in those environments, but there is also a version with optional CommonJS registration.

@Zoramite, I changed test2.js to be a named module with name 'scripts/test2' and then in index2.htm require 'scripts/test2' and then your previous gist works for me.

@jrburke, I guess that makes sense. It it using the full path as the module name.