Python – Module vs Package

Python at run-time keeps a lot of information around about the state of the code it's executing, and exposes quite a lot of it to programmers. So, at run time, there is an actual object (an instance of a class) called a module object that is created when a module is imported. It is a genuine Python object and you can do anything with it that you can do with a Python object. It has methods and everything.

When a function definition that gets executed (which isn't the same as the function being executed - normally the definition would be executed once for the function when the module is imported) it creates a function object, which is just a special kind of object that is a wrapper around the executable code. This too is a real object, you can set variables to it, pass it as a parameter, call it's methods, etc.

I've always used to use build files but since I started my first nodejs project I started using browserify. With browerify and other similar libraries your code is your build file. I am taking advantage of a client and server library that can run on both but it can also work with purely client code. To sum it up browserify gives you all the benefits of writing code in node (no anon functions to avoid globals, npm, simple requires) and it allows you to package that code to run on the client with one command and only load one file.

With browserify you can do something like (named app.js):

var MyLib = require('../myLib');

if(typeof window !== 'undefined') {
    window.MyLib = MyLib;
    window._ = require('underscore');
    window.$ = require('$');
    window.MyLib.myCan = require('./3rdParty/can/can');
}

browserify app.js > client.js

Would produce something like:

[function(require,module,exports){
    window.MyLib = //MyLib code
},
function(require,module,exports){
     window._ = //_ code
},
function(require,module,exports){
    window.$ = //$ code
},
function(require,module,exports){
    window.MyLib.myCan = //can code
}

The file that you would define could have all your 3rd party libs included and not clash with any of your developers that use it.

--Edit in respond to the comment (and a complete miss on the question)

I guess that would depend on your dependencies and how much time you want to spend making sure they work across all versions and libs. If your dependencies are common and follow the same api from version to version you could go the Backbone route and just require the user to have $ and _. I would suggest putting the more obscure libs as part of the bundled file. The options don't have to be cut and dry either. You could offer a pre-built or build your own package.