nice library

[weepy]

hey - nice lib --- this isn't an issue - just giving feedback, feel free to delete.

If you're going to have a credits section - I wouldn't mind being credited for the original require functions - TJ did a light refactor ^_^

[rauchg]

Oh sorry <3 Thanks for those require functions

[tj]

https://github.com/visionmedia/jade/blob/master/support/compile.js#L110

mwahaa. very handy

[weepy]

I wouldn't normally moan, but I was very proud of them :) --- melted my mind for a little while

[tj]

it's handy to have a light-weight implementation to wrap like this without worrying about monolithic or opinionated module loading systems. until the world accepts some standard it's pretty badass

[weepy]

indeed - note it's very similar to brequire ... did you see that ? --- if not more nicely written and presented ... often my downfall when it comes to OS.

Note that if you renamed require.register to define then it would be AMD. This is something I've just changed in brequire.

[tj]

yeah i know, you showed me it a long time ago so i figured i would try it with jade to wrap the lib

[weepy]

-- sorry i meant browserbuild ... has identical aims to brequire.

Having said that I've just added a require.async so you can asynchronously require libs in.

It's quite neat as it statically parses the dependencies and xhr's everything that's not already down. Some might complain using regex's is fragile, but actually it's pretty solid and still comes in at < 200 lines.

On Fri, Dec 2, 2011 at 9:37 PM, TJ Holowaychuk < reply@reply.github.com

wrote:

yeah i know, you showed me it a long time ago so i figured i would try it with jade to wrap the lib

---

Reply to this email directly or view it on GitHub: https://github.com/LearnBoost/browserbuild/issues/2#issuecomment-2996199

[rauchg]

I must have misunderstood. I spent time going through all the NPM libraries for require and commonjs and no one seemed to do just the one thing I needed: a quick CLI interface that gets out of the way.

[plievone]

A few similar libraries with quick CLI interfaces: https://github.com/medikoo/modules-webmake, https://github.com/brentlintner/browsify.js, https://github.com/bnoguchi/browser-require. Perhaps you could compare your implementations?

[rauchg]

browsify.js

..and in the browser you would require the module as expected.

(emphasis mine)

var foo = require('lib/foo');

browser-require

Depends on a server implementation, exposes require to all your client side (browserbuild hides it, uses it only internally)

modules-webmake

Gets very close, but it wraps your original source code too much, and it doesn't allow you to produce a global from your main file easily. The goal of browserbuild is that you can export your main file as window.io for example.

[rauchg]

In addition, webmake performs static analysis to reveal dependencies. The following will work:

require('./b').alert();

The following won't:

var a = require;
a('./b').alert();

Obviously this is normally not an issue, but I do think it overcomplicates the solution.

[plievone]

Thanks for your thoughts! There are so many packaging-related libs on npm (amd, app.js, assets-packager, dryice, ender, folio, hem, jah, js-manager, modjewel, modulator, modul8, modulr, nap, node-ams, node-asset, node-masher, node.packer, one, piler, require, stitch, stitchup... and browserify of course) that it's difficult to work out the best practices. It's interesting to see what directions Express, SocketStream, Derbyjs etc will take. For now I have been experimenting with RequireJS, but mostly the projects have just used its 'optimizer' and then the https://github.com/jrburke/almond loader, so amd have been underutilized. Some libraries, such as underscore and backbone, are more convenient to use as globals. So now perhaps with browserbuild there could be a nicer way, and it could work really well with https://github.com/ded/script.js on those rare async loading needs as they both use globals nicely.

[tj]

@plievone the point of this one is not to provide any kind of module loader, it's simply so you can take an existing node module and package it up for the client-side without adding a bunch of ugly client-side related code directly in your library