modul8 has big flaws /clux

[clux]

For this to be a viable code bundler in the future the resolver/analyzer part of modul8 needs some serious work.

The problem that stands before us is because of the introduction of domains; my homebrew way of sharing code between the server and the client, I have essentially bypassed the standard nodejs require.resolve algorithm and emulated how I thought it worked at the time. This breaks a variety of (uncommon) setups like requiring a directory by package.json (but not in /node_modules) and probably other minor things that will never be quite the same with domains.

So it is essentially impossible to use require.resolve without chucking out domains, and also plugins.
Plugins could still be done in other ways, but not by adding domains like the current setup requires, and probably more like what I've done in combustion so that you are not locked in to the bundler. This also facilitates bundling code by utilizing npm, which is such a great package manager that we can even hook into the good browser projects like ember's tool-chain and use that in a commonjs environment. tl;dr: plugins and domains were a bad idea.

So this leaves two options:

1 rewrite the resolver to properly use node semantics and chuck out domains (this would still leave one damn good CJS packager)
2 use browserify for the packaging and port some of the good work done here to use this

I have semi-recently factored out a lot of common code from modul8 so that the codebase is quite clean, so I think 1) should be a quite doable job. Tests are nicer as well, but are still huge beasts because of all the things that have to be tested via zombie.

As for 2) the one thing that browserify does not do well, but we do, is code analysis (browserify does not build up an internal dependency tree), and I'd really like to have that option, despite what packager I use. But other than that, I really have no qualms against browserify anymore. I thought domains were a good idea (and the docs reflect that), but they are not. @substack got it right.

At the moment, I have very little drive to do this rewrite (this project already took up a lot of my time before xmas, and I'd like to actually make something at this point). In short if someone's willing to continue the project, I'd appreciate it. If not, I'm probably going to fork this project to just do the code-analysis as either a plugin for browserify or as a stand-alone project.

So that's the sad state of affairs. I'll leave this here for a while, as I'm probably not goint to do much. The module is working like before and is now compatible with 0.8. So it should stay working for quite some time.

[Raynos]

@clux would there be value in taking features out of modul8 and adding them to browserify ?

I don't see what modul8 offers over browserify given option 1

[clux]

No, I agree - there's little benefit of redoing something that's been done this well. The only thing I miss is in browserify is .analysis(), and there might be a way of doing that outside the module/as a plugin anyway.