I've run into some problems with uglify handling specific libraries or specific files incorrectly. You've introduce a no_mangle, which could handle most of those cases (I've yet to try it), but that'll kill it for the entire run, not just the file that isn't behaving. What might be nice, assuming it was feasible, is if, for instance, you know that uglify and foo.js don't play nicely, to let foo.js be while going ahead and mangling everything else.
Possibly allow no_mangle to be either the all-or-nothing boolean, but also an array of files/modules.
I am not sure about this -- I do not want the configuration to uglify be so much different than the straight usage of uglify, and my thought is that if uglify is not minifying some things correctly that maybe a custom minification strategy should be done after r.js runs, since it may be because a different version of uglify is needed, it may be better to have more fine-grained control and driving of uglify directly. The bundled uglify is so that the basic use of optimization is easy to do.
I'm open to discussing it more though.
the option I presented in #255 is not uglify specific, just says which files shouln't be optimized.
in my case those are big already minified .js files that take a substantial part of the build time reminifying something that is already minified.
if it sounds interesting I can submit a pull request.
The speed gain by skipping already minified modules is tempting. I'm still on the fence about it being in r.js proper though, the minification could be handled by a post r.js build process. But feel free to talk through a design, what it would look like. I think there is some complication because some config values use module IDs some reference actual file paths.
Closing this out. Forgot I had opened it. I handled this long ago by doing minification before the r.js build, excluding the problem files, and then automatically setting optimize to none. I've had numerous problems with uglify not doing the right thing, so this has been huge.
I had a use case for this feature as well. My app was was a skeleton that references a bunch of pre-built modules with their own testing suites, configs, npm dependencies etc. When I was developing before I set up the dependency management, my grunt was running minification for the tests and node_modules folders inside each module.
Properly setting up my dependency management fixes this problem, but it would've been nice to have some sort of exclude for early development.