Consider env var for the closure library

[casio]

Instead having to clone the closure lib over and over again, it would be nice if users could just set an env var pointing to their local copy.

I dont remember really, but I think there were issues with depswriter.py depending on the cwd, so using deps.js in the browser might pose a problem.

Will have a try with this..maybe you have a solution already?

[thanpolas]

I have a lame alias in my bashrc:

alias cl="ln -s ~/Projects/libs/google-closure-library"

And on each project i do cl closure-library which creates a symlink to the library...

Nevertheless, an env var is more elegant and should be implemented

[casio]

Of course people could just read from process.env in their Gruntfiles, which would be fair enough for me.
Dunno, but I thought that the closure .py scripts where having problems with their cwd dependency.

Anyway, for dev mode, people would need a way to serve up the closure lib files, so maybe to really get rid of cloning into a local folder, some kind of server task would need to host the files from the glolbally localted closure lib?!

[thanpolas]

Network latency for 100+ required files can be a show stopper.

But it might work for getting started... can be worth exploring

[casio]

Network latency for 100+ required files can be a show stopper.

Uhu, I remember plovr having issues with that as well(but I think that was rather related to the java server being used).
If we could configure the connect task to nicely serve the lib files, maybe using rather aggressive caching, that should be ok, no?

We could additionally go for an option, so that the lib files could be served from an already existing server.
However, that would require the closure .py to support providing a full URI in or root_with_prefix, I guess.

So, how do you do during dev?

[thanpolas]

I create a symlink for closure-library inside the project and add 'closure-library' to .gitignore

[casio]

Ok...but then you also serve the lib files from the connect task already(/closure-library/...), no?
I mean, in regards to your network latency argument... maybe I misunderstood this.

When using closureDepsWriter in concert with an env var, we would need some connect middleware that serves the closure js files from that non-project location.

[thanpolas]

There is no (internet) network involved when developing. Closure library is on my hard-disk and available to the project witha a symlink. Connect, the static server, is happy to serve files using the symlink so no issue there. When i was talking about latency i meant the case where we access closure remotely.

I see the problem with the env var now... ye a middleware would be required for this case...

[casio]

When i was talking about latency i meant the case where we access closure remotely

Ah ok, I see : )

Ok, then I'll explore such a middleware a bit...

[casio]

He, actually no additional middleware needed - we can just add another call to mountFolder to the middleware list.

In the connect:livereload target this would look like:

middleware: function (connect) {
  return [
    lrSnippet,
    mountFolder(connect, 'app/'),
    mountFolder(connect, CONF.closureLibrary)
  ];
}

CONF.closureLibrary can then easily be set to an env var(or just the path to the users global closure copy) today already.
The only change thats needed for this to work is in the dev index.html:

<script src="/closure/goog/base.js"></script>

(instead /closure-lib/closure/goog/base.js)

I think this is even more clean than an env var. What do you think?
We could just point this out in the readme and be done.

[thanpolas]

If i understand correctly, we just update the <script> tag and add the mountFolder in Gruntfile?

Then by just working with the global closureLibrary var in Gruntfile we are ok?

[casio]

Yea, it seems so.
Obviously one can merge multiple folders into the connect static middleware.

That makes up for potential naming clashes - if someone would rename the app folder to closure, this might cause problems. But who does this? : )