@dojo/has Plugin

[kitsonk]

Enhancement

Part of the original vision for @dojo/has was that as part of the build process, code could be built out by providing a set of static flags to assert during the build process removing the run-time evaluation of the feature flag and instead substituting the build time assertion.

Therefore the HasPlugin would take something like the below:

import has from '@dojo/has/has';

if (has('foo')) {
  console.log('foo');
}
else {
  console.log('bar');
}

And where the feature 'foo' would be set to true at build time would generate:

import has from '@dojo/has/has';

if (true) {
  console.log('foo');
}
else {
  console.log('bar');
}

Which would during minification get rewritten as:

console.log('foo');

Also, from a consumer API, we should provide an abstraction that allows the user to build without having to understand the details of the flags. We would provide several pre-configured sets of flags which would be reduced to the final set being passed to the plugin. From an end users perspective it would operate something like this:

$ dojo build --target=ie11
$ dojo build --target=ie11,es2015
$ dojo build --target=touch,es2016

[kitsonk]

This should also make it possible for us to eliminate the @dojo/shim/native/* modules. As if we ensure our non-native modules take the static flags appropriately, the blocks defining the shim code should elide in a final build, meaning that we wouldn't have to substitute modules (which we don't have a solution for at the moment anyways). While this does not deal with syntactical targeting, it does deal with functional targeting which is the bigger impact on the build size anyways. (Though as @matt-gadd has identified, the shims aren't significant parts of a build anyways).