support for page specific js files w/browserify

[bshack]

right now there is just global.js what everything is compiled into. Need to allow page specific js files. Logic in page specific js files should be able to leverage libraries and reusable logic in global.js as needed.

[bshack]

load them async?

mark them as external? http://benclinkinbeard.com/posts/external-bundles-for-faster-browserify-builds/

[bshack]

multiple bundles

If browserify finds a required function already defined in the page scope, it will fall back to that function if it didn't find any matches in its own set of bundled modules.

In this way, you can use browserify to split up bundles among multiple pages to get the benefit of caching for shared, infrequently-changing modules, while still being able to use require(). Just use a combination of --external and --require to factor out common dependencies.

For example, if a website with 2 pages, beep.js:

var robot = require('./robot.js');
console.log(robot('beep'));
and boop.js:

var robot = require('./robot.js');
console.log(robot('boop'));
both depend on robot.js:

module.exports = function (s) { return s.toUpperCase() + '!' };
$ browserify -r ./robot.js > static/common.js
$ browserify -x ./robot.js beep.js > static/beep.js
$ browserify -x ./robot.js boop.js > static/boop.js
Then on the beep page you can have:

<script src="common.js"></script> <script src="beep.js"></script>

while the boop page can have:

<script src="common.js"></script> <script src="boop.js"></script>

This approach using -r and -x works fine for a small number of split assets, but there are plugins for automatically factoring out components which are described in the partitioning section of the browserify handbook.

[gibbitz]

So I started looking into this and wrote a long treatise on how to approach run-time dynamic inclusion of files only to realize that this is more about dependency management. My response is more-or-less the same though. I think this is going to need to be managed on a case-by-case basis.

Since I don't like shimming (not all js libraries provide a single entry or depend on polluting the global namespace) I deal with adding third party code to the code-base separate from my (common/AMD/es6) modules. If there's an in-obvious dependency, I'll call it out in either header comments or the documentation.

I see two benefits of managing the code this way: 1) The shim code is not added to the code-base for each library and 2) Future developers can build in a different module system or even vanilla JS without have to become entangled in the dependency scheme complication.

I love the idea of being able to properly manage our dependencies, but short of creating a smarter browserify -- one that looks at the requirements of the whole project and does what we'll need to do manually -- bundle packages dynamically based on usage both statically(<script>) and dynamically($.load(), createElement(), document.write(), eval(), etc.) loaded scripts -- we'll have to actually think about how the code is loaded and built. Honestly, this is what we're paid to do ;).