Audit assert usages

[Pessimistress]

Generally speaking, assert should only be used for sanity checking user-provided parameters and be helpful in debugging.

Change List

• Remove assert on parameters passed between internal code
• Remove assert where it's impossible to fail (e.g. a crash would happen before the assertion is reached)
• Avoid assert in performance critical functions

[coveralls]

Coverage decreased (-2.4%) to 80.66% when pulling 487f6cf on x/assert into 742cff9 on master.

[tsherif]

Great idea. I think I'll do a similar pass in luma.

[ibgreen]

A cleanup was certainly in order.

I have has this idea about asserts:

• we could offer a mechanism to have asserts be removed in production. E.e probe.gl can provide a babel-plugin-remove-assert (a simplification of, or extension of, the log removal plugin that was just added to probe.gl).
• The problem is how apps would apply this plugin - select from multiple library builds, or have their app build systems explicitly apply this plugin on all modules that match /\.gl/?. But such a plugin would remove a bunch of concerns around overhead, especially around bundle size impact of the assert message strings.

[ibgreen]

Many of these asserts can be replaced by simple static type checking. For instance, without even adopting typescript, running the typescript checker and just letting it parse the existing code and jsdoc comment headers, can catch a lot of incorrect parameter passing cases. It does require some massaging of existing code to make it work, I have a proof-of-concept PR in math.gl for that.

[Pessimistress]

probe.gl can provide a babel-plugin-remove-assert

It's not that easy to do it from the application configuration. Depending on which dist env the module is resolved to, transpiled code can look quite different from the source, e.g. layer.js in es5:

_log["default"].deprecated('layer.unprojectFlat')();

geojson.js in es5:

_core.log.assert(geojson.type, 'GeoJSON does not have type');

The app can of course set custom babel rules for the vis.gl dependencies, although the setup would likely be cumbersome and fragile. It is also very difficult to verify that the plugin was indeed effective, without digging into the minified bundle.

If we provide multiple library builds, as you commented before, we wouldn't want to use conditional require, which breaks tree-shaking. We will instead offer the production builds without a valid entry point in package.json, and the user will need to specify their own module resolution rules in their bundle settings.