Use `:file-min` when processing JS modules with advanced optimizations
Currently the `:file-min` option is ignored if a foreign lib is a JS module. Certain libraries produce 2 different artifacts, one which has development time checks, and a production-ready bundle which doesn't.
This patch proposes that `:file-min` in a JS module be fed to the Google Closure Compiler (instead of `:file`) when processing JS modules in `simple` or `advanced` compilation. This way, the development bundle of a JS module can be used with `:optimizations :none`, while the production-ready bundle can be used when compiling projects for production use.
Ok I see now that this isn't really changing what was already there. Why alter-var-root in the tests, that's global side effect no? Why not just with-redefs?
Regarding the first question, this doesn't introduce any implicit magic, the user needs to specify the minified override.
Wrt the 2nd question, we can probably change the behavior of `-relative-path`, but the consumer of this function takes care of calculating the relative path in `rel-output-path`. This is currently how it's done in master, I didn't change that behavior.
To be honest, I don't really think we're overloading a concept more than it's already overloaded in the sense that `min` files are generally viewed as production ready.
Reviewing the patch, I'm somewhat wary of protocol changes but I guess in this case it will be OK because it's just an additional arity. The implementation of -relative-path seems strange where you return nil if the file is absolute. Is this actually respecting the contract?
It's also a little bit annoying that this conceptually overloads `:file-min` since in this case we're not actually talking about min files but `production` files.
One question I have is this for user supplied overrides since I don't see how you can automatically compute `:file-min`? Or do believe just looking for .min.js is good enough for most libraries?