Hi,
I wanted to confirm something before moving forward with an API proposal and hopefully a pull request very soon.
The problem
In Google Land, high upon the mountains, the laws of JavaScript dictate one should use adequate package management, with an a-la Java type provisioning system built with 2 compiler primitives, namely goog.require and goog.provide.
This is perhaps the most powerful feature the Closure Compiler has to offer, and to the best of my knowledge the sbt-js plugin is completely ignoring it by feeding in JavaScript sources to the compiler in parallel for minification only.
Conversely, using the Compiler directly in the "intended" way generally means, beyond the tedious annotations, working with a deps.js file, sub-modules that are auto-included, and a very advanced automated dependency generation and compilation system, dead code elimination, etc.
Without further ado, I would like to have:
In the following file: users/users-service.js
goog.provide('myapp.users.UserService');
/**
* @constructor
* @ngInject
*/
myapp.users.UserService = function($q, $http) {
..//etc
}
goog.addSingletonGetter(myapp.users.UserService);And then in: users/users-controller.js
goog.provide('myapp.users.UserController');
goog.require('myapp.users.UserService');Why would I go through all this trouble? Well, in an ideal world the compiler would then take care of every single .js output file and I would only include the single generated file, just like in the Java world all I need to worry about is a .jar.
Proposed solution
sbt-js should have a mode of feeding JS sources in the Google-esque way, where files are not individually compiled, but rather the entire output is fed to the compiler call in a single go via --input directives and a single output file(or one file per module) is being compiled and generated under a specified path.
For people who are committed to the Closure Compiler beyond simple minification, this seemingly simple change does introduce a new world of productivity, where you no longer need to include a thousand JS scripts in your header manually.
Is this something that's actively being considered or that you would happily merge as adjacent functionality?
Regards,
Hi,
I wanted to confirm something before moving forward with an API proposal and hopefully a pull request very soon.
The problem
In Google Land, high upon the mountains, the laws of JavaScript dictate one should use adequate package management, with an a-la Java type provisioning system built with 2 compiler primitives, namely
goog.requireandgoog.provide.This is perhaps the most powerful feature the Closure Compiler has to offer, and to the best of my knowledge the
sbt-jsplugin is completely ignoring it by feeding in JavaScript sources to the compiler in parallel for minification only.Conversely, using the Compiler directly in the "intended" way generally means, beyond the tedious annotations, working with a
deps.jsfile, sub-modules that are auto-included, and a very advanced automated dependency generation and compilation system, dead code elimination, etc.Without further ado, I would like to have:
In the following file:
users/users-service.jsAnd then in:
users/users-controller.jsWhy would I go through all this trouble? Well, in an ideal world the compiler would then take care of every single
.jsoutput file and I would only include the single generated file, just like in the Java world all I need to worry about is a.jar.Proposed solution
sbt-jsshould have a mode of feeding JS sources in the Google-esque way, where files are not individually compiled, but rather the entire output is fed to the compiler call in a single go via--inputdirectives and a single output file(or one file per module) is being compiled and generated under a specified path.For people who are committed to the Closure Compiler beyond simple minification, this seemingly simple change does introduce a new world of productivity, where you no longer need to include a thousand JS scripts in your header manually.
Is this something that's actively being considered or that you would happily merge as adjacent functionality?
Regards,