Google Closure - extern files

Jan 13, 2011 at 4:10 PM

I just started using this, and it rocks!

My aim for it is to get full compile support for my js files - although all the css min + combine, and ease with which I can combine and min my script is great.

To do advanced compilation though, I need to get some extern files in and also to pick up the type argument erros that come as warnings

To allow this, I have created a fork and have it working.

I added 2 settings:


default --warning_level QUIET so works same as before, but allows for me: --warning_level VERBOSE


If you fill that in (say .externs) then when you do a simple or advanced compile it checks for yourfile.externs.js (by replacing from yourfile.gct.js based on your chosen .gct extension) it passes through to the compiler as --externs.  Default is not to use this.

1 caveat, only works in offline mode

I also made a couple of tweaks to the config file work, as well as fixing a potential inifintie loop I hit.

With this fork I can now use 2 config files to produce combine versions of all my extern and js files, and a second config file to produce simple and advanced versions, and give me compile errors if any types are wrong / undefined etc. (note: we use .com.js to indicate a js file should be combined and compiled)


<?xml version="1.0"?>
  <FileGroup Name="core.debug.externs.js">
    <Folder Minify="false" Pattern="*.extern.js"/>
  <FileGroup Name="core.debug.js">
    <Folder Minify="false" Pattern="*.com.js"/>
<?xml version="1.0"?>
<FileGroup Name="core.min.js">
    <File Minify="true" Path="core.debug.js" MinifyWith="gctSimple"/>
  <FileGroup Name="core.minh.js">
    <File Minify="true" Path="core.debug.js" MinifyWith="gctAdvanced"/>
Hope that all makes sense, take a look at the fork, and let me know what you think?

also, for the latest stuff on refactoring the config, I assume that is work underway as a few issues with the logic for minify seperately
(because missing attributes on files / folders arent taken from the fileGroup) and also looked like if minifySeperately was false, it didnt actually minify?
or should I pop what I found in the issue tracker?

Jan 13, 2011 at 9:07 PM

To be honest i forgot to add defaulting back in. Committed it back in now along with some other small fixes. Thanks for rubbing my face in it :)

I love the --extern support.

If you move the MinifyWith attribute to the FileGroup it will call gctAdvanced once after combining. In alot of cases this removes the need of calling --extern i would think.

Do you need two config files for it too work though ? Since Directory.GetFiles loads them in alphabetic order it might get confusing. Or was it my sloppy commit that introduced this? 

Jan 14, 2011 at 9:26 AM

yeah sorry - wasnt meant to be a face rubbing!

Issue I was getting with 1 config file was it seemd to recursively call - worked fine from the console app, but when running as an add in it kept looping, even after I moved the manager.Process above the refreshconfigfiles

Sure it must just be a dependency as effectively I wanted fileGroup1 to group everything together, and then filegroup2 to gct it, but guess that makes FG2 dependant on FG1 so causes the loop?

In the end, I sort of lost patience trying to figure it and the 2 files are fine for me... perhaps worth a test after your changes?

For us, we'll still need externs anyway for jquery and a couple of other apis that we ref scripts froma cdn so cant alter signatures.

Jan 14, 2011 at 3:56 PM

slightly off topic - with a folder group, is there anyway to reference scripts outside of the current folder, so if my structure is:


- controls

- pages

- scripts

and I want to have a config in teh scripts folder pick up .js files in the controls folder?  tried using Path="~/controls" but no joy


Jan 17, 2011 at 10:55 AM

I rewrote pattern handling to handle 

Fixed paths (d:\somepath\x\*.js, \\some\network-path\*.js)

Relative paths ("..\..\scripts\*.js, ".\scripts\*.js)

paths that start with a / or \ however are treated as being rooted to the config directory. ~/ would result in two different meanings in console mode and when ran in VS. If you have any suggestions i would love to hear them.

also the Recursive attribute might now be confusing when using paths like d:\somepath\x\*.js Deep="True" might be less ambigious ?

Jan 18, 2011 at 9:52 AM

sounds great, giving it a go now.

Agree on deep vs recursive.

Only other thing I can think of is getting all the sections in 1 config - but I was getting it recursively rebuilding teh files when I did that - will give it another go on latest code though.

I was also going to add in config for where to find the closure compiler

what is best approach for merging down from my fork?

Jan 18, 2011 at 2:40 PM

Gave it a go and works really well.  Unfortunately I still get the recursuive issue with the following config:

<FileGroup Name="core.debug.externs" Minify="False">
    <Folder Minify="false" Pattern="*.extern.js" />
  <FileGroup Name="core.debug.js" Minify="False">
    <Folder Minify="false" Pattern="*.adz.js" Path="..\controls"/>
  <FileGroup Name="core.min.js">
    <File Minify="false" Path="core.debug.js" MinifyWith="gctAdvanced"/>

but having the 2 configs works fine for now.

I've also made a start on specifying where the jar file sits and works fine for full paths but not relative yet.


Jan 20, 2011 at 6:01 PM

Hey bakesteve,

Had a busy week i hope to commit my patches asap. That recursive thing needs to be solved too though since you have no control in which order configs are loaded apart from naming them alphabetically :)

About merging, you could either request developer access from weirdlover or i can pull from you and merge + commit. Whichever one happens first :)

Jan 21, 2011 at 10:02 AM

sure - will do.  I've rejigged things a little so all based off your changes on file configs in the trunk.  I'll ask weirdlover, but probably also just recreate my fork and then maybe you can pull the changeset down?


been using a bit more now and started playing with a couple of other changes/fixes:

1 - made closure compiler write output / errors async - I was getting a problem where the compiler hung and that then seemed to stuff the thread all chirpy work was on - this way I kill the compiler process if it takes too long.

2 - On my project we'll be combining a lot of script, so would probably like the option to only compile on build, not via file saves - thought initially that could go as a chirpy setting, but think it probably makes more sense on a config file setting so you can vary betweeen projects?  Having a go at that now.

3 - for the recursive - any ideas on best way to debug this or is it just a matter or using the chirpy output window to put out some text?  All works fine in console mode, so a bit tricky to track down.  I'm also getting times when teh filedependencies seem to get lost - chirpy picks up that I saved a file (ie that is handled by my config - but the config engine doesnt get run unless I change & save the config file

Jan 21, 2011 at 3:05 PM

quick update on #3 - when dependencies werent being picked up - the issue was I had moved to the new relative path, which was great, but the path for the file created in folderXML included teh relative parts which handled but dependencies didnt

the fix is to change folder xml line 29 to use GetFullPath to resolve a path of c:<user\docs\etc\>..\..\pages\scripts\file.js

FileXmlList.Add(new FileXml {
Minify = this.Minify,
Path = System.IO.Path.GetFullPath(filePath),//handles relative paths - needed for file dependency to work later
MinifyWith = this.MinifyWith

not tracked down the recursive part yet - thats next!