This reworks the changes in #2442 so we always include the version info, regardless of whether the module is run as main or not. This also addresses a few lint related issues.
If a `src` config is not provided, by default, all of the library sources are included. There is some special handling in the build task to make sure all library sources are included regardless of the path to the build config. When someone includes a `src` config, path patterns are assumed to be relative to the current working directory (unless overriden with the `cwd` config). So, when you use the `src` config, your config is no longer portable.
Because we don't know if a new or modified file includes changes to the class hierarchy, we regenerate info for all sources any time any one has changed. An alternative would be to generate info first for the new or modified file and then (potentially) regenerate info for more source files in the class hierarchy, but this makes the generate-info.js task far more complicated.
The test.js task starts the development server and runs the tests in PhantomJS. As mentioned in the readme, when running the tests continuously during development, it is more convenient to start the dev server and visit the root of the test directory in your browser.
Later we can bring in Karma to drive PhantomJS and other browsers, but this simple "run once" task is useful for the CI job.
By default, all paths in the build config (e.g. externs) are assumed to be relative to the ol3 repo root. To make it so relative paths are resolved from a different directory, use the cwd option.
In addition, this change makes it so the `build.js` task can be run from another directory.
This is to accomodate the case where other directories than "ol" include "api" annotations. For example, the Swisstopo geoadmin folks extend OpenLayers 3 in an ol3 fork, and they have their own "ga" namespace/directory under "src". See https://github.com/geoadmin/ol3/tree/master/src.
This allows users to build ol3 without anything exposed in the
global namespace. This can e.g. be useful for creating an ol3
AMD module, by simply using a build configuration with
"define('ol',function(){var o={};%output%return o.ol;});" as
"output_wrapper".
Whitespace builds are still painful to debug. Skipping the compiler altogether and simply concatenating sources is a better option for development and debugging. By ommitting the `compile` option in a build config, the output is "uncompiled" - a straight concatenation of all sources in dependency order.
This task generates build related metadata for the library based on doc annotations. Since it is about more than writing out exportable symbols, it makes sense to have a more general name.
The generate-symbols.js task runs JSDoc on source files. Because this takes a long time (13s) to run on the whole library, the resulting symbols file includes additional metadata to make it possible to do incremental symbol generation on subsequent runs. The 'path' and 'extends' metadata for a symbol are used to determine what needs to be regenerated.
This runs JSDoc with the "symbols" config, providing a list of source files that have been changed since the previous run. The output is used to generate a symbols.json metadata file containing all exportable symbols info. A separate task will be run to generate the exports.js file. These same metadata files will be used by a build tool.
This strips markup from elements with id attributes that we care about: title, shortdesc, tags. This will only work for people who use `npm install && npm start` to browse examples. The other example parser doesn't strip this markup, so it should still not be used in these elements.
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.
