You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.
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:
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:
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).
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:And where the feature
'foo'
would be set totrue
at build time would generate:Which would during minification get rewritten as:
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:
The text was updated successfully, but these errors were encountered: