After revisiting this and trying some more things, I finally wrapped my head around what browserify-shim is doing and how to use it. For me, there was one key principle I had to grasp before I finally understood how to use browserify-shim. There are basically two ways to use browserify-shim for two different use cases: exposing & shimming.
Background
Let's say you want to just drop in a script tag in your markup (for testing or performance reasons like caching, CDN & the like). By including a script tag in the markup the browser will hit the script, run it, and most likely attach a property on the window object (also known as a global in JS). Of course this can be accessed by either doing myGlobal or window.myGlobal. But there's an issue with either syntax. It doesn't follow the CommonJS spec which means that if a module begins supporting CommonJS syntax (require()), you're not able to take advantage of it.
The Solution
Browserify-shim allows you to specify a global you'd like "exposed" through CommonJS require() syntax. Remember, you could do var whatever = global; or var whatever = window.global; but you could NOT do var whatever = require('global') and expect it to give you the right lib/module. Don't be confused about the name of the variable. It could be anything arbitrary. You're essentially making a global variable a local variable. It sounds stupid, but its the sad state of JS in the browser. Again, the hope is that once a lib supports CommonJS syntax it will never attach itself via a global on the window object. Which means you MUST use require() syntax and assign it to a local variable and then use it wherever you need it.
Note: I found variable naming slightly confusing in the browserify-shim docs/examples. Remember, the key is that you want to include a lib as if it were a properly behaving CommonJS module. So what you end up doing is telling browserify that when you require myGlobal require('myGlobal') you actually just want to be given the global property on the window object which is window.myGlobal.
In fact, if you're curious as to what the require function actually does, it's pretty simple. Here's what happens under the hood:
var whatever = require('mygGlobal');
becomes...
var whatever = window.mygGlobal;
Exposing
So with that background, let's see how we expose a module/lib in our browserify-shim config. Basically, you tell browserify-shim two things. The name you want it accessible with when you call require() and the global it should expect to find on the window object. So here's where that global:* syntax comes in. Let's look at an example. I want to drop in jquery as a script tag in index.html so I get better performance. Here's what I'd need to do in my config (this would be in package.json or an external config JS file):
"browserify-shim": {
"jquery": "global:$"
}
So here's what that means. I've included jQuery somewhere else (remember, browserify-shim has no idea where we put our tag, but it doesn't need to know), but all I want is to be given the $ property on the window object when I require the module with the string parameter "jquery". To further illustrate. I could also have done this:
"browserify-shim": {
"thingy": "global:$"
}
In this case, I'd have to pass "thingy" as the parameter to the require function in order to get an instance of the jQuery object back (which it's just getting jQuery from window.$):
var $ = require('thingy');
And yes, again, the variable name could be anything. There's nothing special about $ being the same as the global property $ the actual jQuery library uses. Though it makes sense to use the same name to avoid confusion. This ends up referencing the the $ property on the window object, as selected by the global:$ value in the browserify-shim object in package.json.
Shimming
Ok, so that pretty much covers exposing. The other main feature of browserify-shim is shimming. So what's that? Shimming does essentially the same thing as exposing except rather than including the lib or module in HTML markup with something like a script tag, you tell browserify-shim where to grab the JS file locally. There's no need to use the global:* syntax. So let's refer back to our jQuery example, but this time suppose we are not loading jQuery from a CDN, but simply bundling it with all the JS files. So here's what the config would look like:
"browser": {
"jquery": "./src/js/vendor/jquery.js", // Path to the local JS file relative to package.json or an external shim JS file
},
"browserify-shim": {
"jquery": "$"
},
This config tells browserify-shim to load jQuery from the specified local path and then grab the $ property from the window object and return that when you require jQuery with a string parameter to the require function of "jquery". Again, for illustrative purposes, you can also rename this to anything else.
"browser": {
"thingy": "./src/js/vendor/jquery.js", // Path to the local JS file relative to package.json or an external shim JS file
},
"browserify-shim": {
"thingy": "$"
},
Which could be required with:
var whatever = require('thingy');
I'd recommend checking out the browserify-shim docs for more info on the long-hand syntax using the exports property and also the depends property which allows you to tell browserify-shim if a lib depends on another lib/module. What I've explained here applies to both. I hope this helps others struggling to understand what browserify-shim is actually doing and how to use it.
Anonymous Shimming
Anonymous shimming is an alternative to browserify-shim which lets you transform libs like jQuery into UMD modules using browserify's --standalone option.
$ browserify ./src/js/vendor/jquery.js -s thingy > ../dist/jquery-UMD.js
If you dropped that into a script tag, this module would add jQuery onto the window object as thingy. Of course it could also be $ or whatever you like.
If however, it's requireed into your browserify'd app bundle, var $ = require("./dist/jquery-UMD.js");, you will have jQuery available inside the app without adding it to the window object.
This method doesn't require browserify-shim and exploits jQuery's CommonJS awareness where it looks for a module object and passes a noGlobal flag into its factory which tells it not to attach itself to the window object.
