As mentioned in the comments, calling goog.getUid and goog.events.listen on the global object (as done in map.js and deviceorientation.js) set global properties. To let Mocha check for other leaks, we preemptively set these properties.
It looks like at some point the Closure Library exposed a public `date` property for this same purpose. The version of the Closure Library that comes with the closure-util package uses this property. At some point later, I'll demonstrate how we can control which version of the library we depend on.
This provides some initial development utilities for people using Node.
Instructions for installing:
npm install
After pulling down the dependencies, you can start a developement server that provides the libraries (ol and Closure Library) in debug mode (not minified/compiled). Run the dev server with the following:
npm start
Currently, the example index page needs to be built with `build.py`. After building that, you should be able to browse all static files, view the examples and run the tests.
This was unused before 03f7bb66374b162aab26289b761e7918b79c0ca7 as well. It would be interesting to see how many other unused requires there are (types that are only referenced in comments but not used in code).
I remain uncertain about when to use the @exportClass annotation and when to use the @exportSymbol. osmsource.exports seems to get away with simply @exportSymbol, but many other sources use @exportProperty.
It looks like the convention in the Closure Library is to export either namespaces (starting with lowercase), constructors (starting with uppercase), or enums (all uppercase, one instance). I don't see any places where the Closure Library exports a function that is not a constructor.
Following the same convention, when we export `ol.foo`, it means we are making available function properties of the `ol.foo` object that start with a lowercase letter.
This follows the convention in the Closure Library of providing either namespace objects (where the property starts with a lowercase letter), constructors (where the property starts with an uppercase letter), or enums (all uppercase properties, only one instance of this in the closure library).
I'm adding this example to demonstrate a few things that should change:
* the icon symbolizer should accept xOffset and yOffset in pixels
* the `ol.geom.Geometry.prototype.getCoordinates` method should be exported
* overlays should have a `panIntoView` method
When people need to serialize in a format that differentiates string concatenation from addition, they can use the new `concat` function in an expression. But I don't think we need to throw if people use `+` with strings.
There are times when we parse from XML without a schema (e.g. KML). In these cases, features attributes will always be strings. We can cast to number when creating literals from symbolizers and then assert `!isNaN` instead of asserting that they are numbers before.
When a style has no rules, the "else" symbolizers apply. When a style has rules and none of them apply to the given feature, the "else" symbolizers apply. Note that this is different than default symbolizer properties that might be merged into all symbolizers (as in OL2) - I don't think we should support that.
Tim Schaub