consider removing build system support
Opened this issue · 7 comments
By removing support for a few particular build systems, you can save yourself a lot of trouble long-term, because there will be an infinite list of systems that people will lobby to add over time.
Already people are petitioning for:
Worse, I think much of the time will be spent maintaining these build tool integrations over time compared to the core concerns of the library itself. This also will cause less churn in the project itself because you won't need to constantly upgrade for upstream changes in build systems.
Part of me is inclined to agree with you: The compiler should just be a tool with a well-documented command-line interface, and then if people want to integrate it with their favorite build tool, they can do so, and hopefully it's not too hard to do.
On the other hand, for the build system integrations we already have, I don't mind keeping them around, as long as folks understand that we're going to spend most of our time on maintaining the compiler itself and not those integrations. Maybe someone can write a wiki page to that effect.
I also seem to remember that we struggle with dependant projects (those build systems) having fixed version dependencies on us, and then getting stuck on older versions of the compiler. That might just be an inherent problem with NPM (.. although to be fair, our version numbers might break semver from that point of view).
I'm also with @MatrixFrog: there's actually nothing stopping people doing this anyway.
Perhaps break the build system support out into separate modules - this gives more flexibility with different compiler/build system versioning, and allows each module to stick to one concern.
I'd be happy to work on the gulp support module, as I'm sure would many others.
I support breaking out support for these features into custom modules.
By removing support for a few particular build systems, you can save yourself a lot of trouble long-term, because there will be an infinite list of systems that people will lobby to add over time.
I'm not sure I could share this sentiment. Of course we (the webpack org) would be happy to maintain a plugin/loader. And I do agree that it's not the cc-js teams responsibility to work on or maintain something like that.
That being said, no one should discourage opportunities for collaboration on these things. For example, It would be incredible to be able to pass a set of modules' sources similar to --modules, so that tools like webpack can really benefit from it!!!
At any length if you all would like us to help or take ownership of this piece I would be happy to help, and if there are any API questions or concerns please drop us a line.
Hello, I was referred to this page via a stack overflow question I created (http://stackoverflow.com/questions/41467710/closure-compiler-js-and-grunt).
To all in thread:
I do not agree that removal needs to be considered. I feel that if build systems support is removed it risks lowering the usage of closure-compiler-js and tbh I think all of us can benefit from our favorite websites (and our own) that uses a good JS-compiler. Especially now when JS is getting more and more heavy on websites.
Also, websites that have been built and is already up and running that uses build systems like gulp or grunt can also benefit from closure compiler that does not have java dependency.
That being said, to have support for it in separate modules is probably a great idea as long as these modules have dependencies to preferred version of closure-compiler-js.
To developers at closure compiler:
Keep up the good work! This is something I've been looking out for for quite a while.
@japalo "dependencies to preferred version of closure-compiler-js" I think is a problem that @substack was trying to solve with the suggestion. The right design is for such plug-ins to not have a hard dependency on any specific version of the tool they are integrating, but rather that as the consumer you are free to pick up as new or old of the main tool (closure-compiler-js) as you like, and use it with the latest, most fixed plug-in packaged separately.
(Of course this goal is sometimes not reached, there are API changes and other obstacles.)