Closure Compiler support in minification mode only

[alexflav23]

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,

[davegurnell]

Hi Flavian,

I'm not opposed to adding this (especially if you have a PR with tests).
However, I'm surprised that there are no SBT plugins out there that do it
already.

If we added support for goog.require, it would make sense to add support
for CommonJS require as well. Is your PR structured in such a way that
this could be added in the future?

Cheers,

Dave

On 8 April 2015 at 13:05, Flavian Alexandru [email protected]
wrote:

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('mypp.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,

Reply to this email directly or view it on GitHub
#70.

Dave Gurnell, Untyped
http://untyped.com
07967 004805

[alexflav23]

Hi @davegurnell ,

Finally got round to wanting to set this straight. 8 months later but nonetheless, I will try to create a PR of this, if you have any warnings or pre-pointers let me know, I'll admit the codebase looks somewhat cryptic as I'm not familiar with the SBT API but otherwise it should be straightforward.

Regards,
Flavian

[davegurnell]

Hi Flavian,

No pointers that I can think of. Please go ahead. There's some good stuff
somewhere on the SBT web site that might illuminate the structure of the
codebase. IIRC this is a good place to start:

http://www.scala-sbt.org/0.13/docs/Plugins-Best-Practices.html

Best regards,

Dave

On Wed, Jan 13, 2016 at 7:07 PM Flavian Alexandru [email protected]
wrote:

Hi @davegurnell https://github.com/davegurnell ,

Finally got round to wanting to set this straight. 8 months later but
nonetheless, I will try to create a PR of this, if you have any warnings or
pre-pointers let me know, I'll admit the codebase looks somewhat cryptic as
I'm not familiar with the SBT API but otherwise it should be
straightforward.

Regards,
Flavian

—
Reply to this email directly or view it on GitHub
#70 (comment).

[davegurnell]

FYI -- I did a bit of housekeeping today. You may want to rebase if you're launching into dev work:

• reconfigured the tests to reliably pass the current plugin versions to the sbt-scripted test scripts;
• integrated with Travis;
• moved published artefacts to Bintray;
• released version 0.8;
• bumped the version number to 0.9-SNAPSHOT.

The big plus is the change to the tests, which should be easier to maintain and more reliable.

Cheers,

Dave