cleaning up unneeded requires

[John Munro]

As I'm still learning the Closure Library, I mostly find something I want to use in a sample, copy it into my web app and modify it to suit.

My web app is at an early stage so it still undergoes serious changes on a daily basis.

Because of a combination of these two things, I sometimes end up with superfluous goog.require lines in my js files.  I don't want to be including parts of the library that I don't need, so I'd like to get rid of them, but it's hard for me to tell what's needed short of commenting a line out and seeing what breaks.

Is there an automated way to detect and remove these?

[James Deyerle]

Use the linter:

https://developers.google.com/closure/utilities/

I have a script that looks something like this:

gjslint \

  -r ../js_src \

  --closurized_namespaces="goog,myrootnamespace" \

  --strict \

  --jslint_error=all \

  --check_html

This will also catch things like unused private members which is really quite handy.  It comes with an automatic fixer called fixjsstyle as well.  I run these two all the time to keep things pruned.

--
 
---
You received this message because you are subscribed to the Google Groups "Closure Library Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Munro]

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-discuss+unsub...@googlegroups.com.

[Guido Tapia]

  --closurized_namespaces="goog,myrootnamespace" \

Wow never knew about closurized_namespaces property.  I must admit I got a bit excited but after testing this I got a lot of errors; fixjsstyle added tons of invalid requires to global/static fields/functions/members.  And it cleaned up unused requires that are actually used.  A few example of the errors are:

Error 1: Say I have a static / globals file like:

goog.provide('ns.defaultformats');

ns.defaultformats.dateFormat = new goog.i18n.DateTimeFormat(datepattern);

... // Other defaults / globals here

If I use this somewhere else, I expect to:

goog.require('ns.defaultformats');

...

var dateformat = ns.defaultformats.dateFormat;

However, the closurized_namespaces addedd a require to ns.defaultformats.dateFormat which gjslint correctly identifies as not having been provided.

Error 2: Removing namespace imports.

I like the java style of importing namespace.*;  To do this in closure I sometimes use what I call namespace files.  An example may be this:

goog.provide('ns.dal');

goog.require('ns.dal.User');

goog.require('ns.dal.Account');

goog.require('ns.dal.UserSettings');

goog.require('ns.dal.AccountSettings');

...

And then in any file that needs to use my model (data access layer) I just import ns.dal goog.require('ns.dal') this is a nice workaround for missing wildcard imports but again not compatible with closurized_namespaces.  

After this I reverted my changes so not sure if any other conflicts with my codebase exist.

Anyways, would love to see closurized_namespaces be a bit smarter.

Thanks for the heads up tho James, it is an interesting feature

Guido

[James Deyerle]

Part of getting fixjsstyle to work well for you is to tweak your code a bit.

On Mon, May 20, 2013 at 3:14 PM, Guido Tapia <guido...@gmail.com> wrote:

  --closurized_namespaces="goog,myrootnamespace" \

Wow never knew about closurized_namespaces property.  I must admit I got a bit excited but after testing this I got a lot of errors; fixjsstyle added tons of invalid requires to global/static fields/functions/members.  And it cleaned up unused requires that are actually used.  A few example of the errors are:

Error 1: Say I have a static / globals file like:

goog.provide('ns.defaultformats');

ns.defaultformats.dateFormat = new goog.i18n.DateTimeFormat(datepattern);

... // Other defaults / globals here

For this, I think you can just adjust the capitalization?

ns.defaultformats.DATE_FORMAT

or

ns.defaultformats.DateFormat

I think the linter behavior will change for you by doing this.

 

If I use this somewhere else, I expect to:

goog.require('ns.defaultformats');

...

var dateformat = ns.defaultformats.dateFormat;

However, the closurized_namespaces addedd a require to ns.defaultformats.dateFormat which gjslint correctly identifies as not having been provided.

Error 2: Removing namespace imports.

I like the java style of importing namespace.*;  To do this in closure I sometimes use what I call namespace files.  An example may be this:

goog.provide('ns.dal');

goog.require('ns.dal.User');

goog.require('ns.dal.Account');

goog.require('ns.dal.UserSettings');

goog.require('ns.dal.AccountSettings');

...

I have encountered this problem as well and you can do this with suppression annotations so you can get the awesome auto behavior elsewhere:

/** @suppress {extraProvide} */

goog.provide('ns.dal'); 

/** @suppress {extraRequire} */

goog.require('ns.dal.User');

/** @suppress {extraRequire} */

goog.require('ns.dal.Account');

/** @suppress {extraRequire} */

goog.require('ns.dal.UserSettings');

/** @suppress {extraRequire} */

goog.require('ns.dal.AccountSettings');

And then in any file that needs to use my model (data access layer) I just import ns.dal goog.require('ns.dal') this is a nice workaround for missing wildcard imports but again not compatible with closurized_namespaces.  

After this I reverted my changes so not sure if any other conflicts with my codebase exist.

Anyways, would love to see closurized_namespaces be a bit smarter.

Thanks for the heads up tho James, it is an interesting feature

Guido

--

 
---
You received this message because you are subscribed to the Google Groups "Closure Library Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Overall, I have found that the automatic behavior you get with fixjsstyle is well worth the few edge cases that necessitate the @suppress annotations.

[Guido Tapia]

The @supress are great However the following is really ugly:

For this, I think you can just adjust the capitalization?

ns.defaultformats.DATE_FORMAT

or

ns.defaultformats.DateFormat

Code that is upper camel case just does not feel right in JS.  How does code in the closure library get around this?  There are so many static helpers in closure lib and they don't use upper camel (Just look at all the statics in base.js)?

[Guido Tapia]

I take that back.  It does not apply to static functions only fields and I can live with that.

Thanks for the tips James

[Guido Tapia]

Circular Deps are now kicking my butt and with a code base this big (100k lines +) I cannot refactor these out. :(  

My diffs do look nice tho, this cleaned up heaps of redundant goog.require code but I don't think I'll be able to use it long term.