I agree with almost all of this. I've examined and rejected the YUI builder several times over the last couple years, since it never seemed to justify the buy-in cost. It looks super-cool in theory, but in practice I never felt like it was worth the investment time. Below are some of my thoughts:
The builder requires maintaining java properties and ant build files to work. I'm a fan of neither .properties or ant xml files. I think this needlessly complicates the build toolchain with various configuration options that aren't documented. If there must be per-module configuration, it should probably be something like JSON.
It would be really cool if the builder also generated (and the YUI loader knew about) a fourth module definition. We have -debug, -min, and raw. I propose that there be an optional -instrument, which is the YUITest-instrumented version of a particular module. Right now, it's tricky coming up with a quality test/instrument/code coverage strategy, since the instrumenter doesn't know about the builder and vice-versa. It would be amazing if this were baked into a revised YUI Builder.
For the project I'm currently working on, I wrote a lightweight builder script myself in nodejs. The default behavior is to watch source directory and to regenerate the relevant built files into another directory tree any time a module has changed. This is nice, since there's only a couple-second lag time between save and deploy.
Module names are determined by directory structure, so a file named 'baz' in directory 'bar' in directory 'foo' would be a submodule 'foo-bar-baz' in the module 'foo-bar'. The foo-bar module is just a 3.4-style virtual rollup of every foo-bar submodule. This makes it reasonably easy to refactor code into separate modules as the needs of the project change, since typically a module doesn't need to know its own name. I haven't solved the problem of how to resolve module name changes in other modules, though.
Right now, I'm storing dependency configuration in a JSON file at the root of the source directory. The JSON is munged into both a YUI_config object and the module metadata at the foot of each YUI module. At some point I'm planning on moving that configuration into the files themselves (I haven't decided exactly how) and using an AST parser to tease them out, which should simplify dependency management.
The builder requires maintaining java properties and ant build files to work. I'm a fan of neither .properties or ant xml files. I think this needlessly complicates the build toolchain with various configuration options that aren't documented. If there must be per-module configuration, it should probably be something like JSON.
It would be really cool if the builder also generated (and the YUI loader knew about) a fourth module definition. We have -debug, -min, and raw. I propose that there be an optional -instrument, which is the YUITest-instrumented version of a particular module. Right now, it's tricky coming up with a quality test/instrument/code coverage strategy, since the instrumenter doesn't know about the builder and vice-versa. It would be amazing if this were baked into a revised YUI Builder.
For the project I'm currently working on, I wrote a lightweight builder script myself in nodejs. The default behavior is to watch source directory and to regenerate the relevant built files into another directory tree any time a module has changed. This is nice, since there's only a couple-second lag time between save and deploy.
Module names are determined by directory structure, so a file named 'baz' in directory 'bar' in directory 'foo' would be a submodule 'foo-bar-baz' in the module 'foo-bar'. The foo-bar module is just a 3.4-style virtual rollup of every foo-bar submodule. This makes it reasonably easy to refactor code into separate modules as the needs of the project change, since typically a module doesn't need to know its own name. I haven't solved the problem of how to resolve module name changes in other modules, though.
Right now, I'm storing dependency configuration in a JSON file at the root of the source directory. The JSON is munged into both a YUI_config object and the module metadata at the foot of each YUI module. At some point I'm planning on moving that configuration into the files themselves (I haven't decided exactly how) and using an AST parser to tease them out, which should simplify dependency management.