Two ways to use the library: advanced compilation (prod) or raw/concatenated (dev)

[tschaub]

This reduces the number of ways we support using the library. While it is possible to build the library with a dizzying array of options, it is designed to be used with ADVANCED_OPTIMIZATIONS in production. We also offer a way to debug the library during development.

These changes remove the following build targets:

• build/ol-whitespace.js (replaced by build/ol-debug.js)
• build/ol-simple.js
• build/ol-all.js

The build/ol-debug.js target can be used as a single script for debugging (this was not the case with build/ol-whitespace.js). The build/ol-whitespace.js target generated 404s while trying to fetch deps.js. The build/ol-simple.js and build/ol-all.js targets were ways that we demonstrated we could exercise the Compiler, and provided no real value in my opinion.

[ahocevar]

Awesome! Please merge.

[probins]

I'd agree that all these can be removed as part of CI (I've never been able to understand why Travis has to build them all every time), but I think there should continue to be a hosted simple build. Particularly when working remotely, and particularly on poor-quality connections, a raw build is far too big and unwieldy. To my mind, a simple build is a good compromise: much smaller than raw but easier to read/follow than advanced

[tschaub]

@probins with apologies, I'm not compelled. There are two modes of operation I'd like to support: development and production.

For production, we have enough of a challenge ahead of us to provide hosted builds of the library (the full build even with advanced compilation is inappropriate for production). I don't want to mislead anybody into thinking that "simple" or "whitespace" compiled versions of the library should ever be used for production. Having one compiled target (that is still inappropriate for production) is enough.

For development, with this change we still have three ways to debug. First, we host an ol-debug.js script. This is very clearly named, and nobody should be mislead into thinking they can use it during production. Second, if you download a distribution and install dependencies, you can run a debug server. Third, if you are just poking around, our hosted examples can be run in "raw" mode.

@probins please continue to compile simple or whitespace builds for yourself if you find these useful. But I'm pretty firm on not encouraging anybody else to do the same.

[probins]

ok, @tschaub, I understand your concerns. There is another possibility for helping developers debug their code, which is for the hosted builds to make source maps available for the advanced build. I use simple not primarily for debugging but to get non-obfuscated variable names. So another suggestion would be for the hosted builds to also have the renaming reports available online. None of these should be in Travis/ci target, just in the process creating the hosted advanced build.

[ahocevar]

I think @probins's concerns can be handled separately, and I still think this should be merged. Just my 2¢.

[probins]

I agree. I don't have a problem with this being merged. But I think there needs to be further thought on what builds apps developers will want to use and how.

[tschaub]

Anybody who has tried debugging a compiled ol3 app with a source map will know that it is a horrible experience.

[elemoine]

For posterity: the goal of the buuld-all target was to throw all the source files to the compiler, to check that the entire code base compiles without errors.