Introduce feature flags

[senadir]

This PR introduces a simple feature flag and gate features, as a start, it will only prevent Checkout and Cart from being registered.

It introduces 3 flags 2 flags: Core, Stable, and Experimental.

Any code not gated is considered stable enough to be included in Woo Core.

Experimental is code that is not stable yet to be shipped, think Cart and Checkout blocks by the end of last cycle.

For development purposes, the default flag will be experimental.

We also append WOOCOMMERCE_BLOCKS_PHASE="stable" to the build command in npm run deploy.

To achieve this, I used a combo of DefinePlugin of webpack and an env variable WOOCOMMERCE_BLOCKS_PHASE.

This code heavily inspires from WordPress/gutenberg#13324

Fixes #1500

[senadir]

This is set to Draft and in Progress because I didn’t yet manage to get it to work, I only tagged for review to help determine why it’s not working (something specific about our build process?)

[senadir]

Moving the config to webpack-helper fixed the issue, all working right now.

[nerrad]

Thanks for taking this on @senadir 👏 This is going to be really useful for the work we're doing in this repo and gating things until it's ready for release. However, there are some problems with the current implementation and I also have some things I think we should consider:

• the frontend builds (getFrontConfig) and coreConfig might have gating as well so we should probably include the plugin definition in those configs too. I think this should be done before merging this pull.
• While this works well for gating what javascript executes or not, there is no gating php side, so that means built javascript for gated features will still be enqueued and loaded. I don't think we need to tackle that in this pull but we probably should create a follow-up issue to discuss how we might handle that (or if we should bother).

[senadir]

So my latest changes are not complete.

I addressed the feedback and added even more gating, since we output a js file for each block (well, 2 files), i moved those to experimentalFrontendEntry and experimentalMainEntry, I left the stable ones in stableFrontendEntry and stableMainEntry, and according to the flag, I merge them.

this will cause some html errors since PHP will enqueue a nonexistent file, I'm adding some feature gating to PHP as well, but we still need a way to define the constant at run time.

[nerrad]

Liking how this is coming along! Thanks for addressing all the feedback. Just a few more things to take care of 👇

[nerrad]

Great idea to split out the stable from experimental configuration!

[nerrad]

Is this needed if the default is experimental (npm build or npm build:ci executed on their own will be using experimental too)?

[senadir]

now that we have default values in PHP as well, we don’t need to pass this yeah.

[nerrad]

Awesome Nadir! Soooo close to merge ready. I've tested and verified that the woo-blocks.ini file has the correct value written to it depending on the WOOCOMMERCE_BLOCKS_PHASE environment 👍

I just have a few more comments that should be addressed.

[senadir]

@nerrad addressed the latest comments, this is ready for another spin

[nerrad]

I have a suggestion for improving the php side detection of the blocks phase flag.

PHPUnit test jobs for travis are currently broken because of the default to stable when the block.ini file isn't present. We don't run webpack in the phpunit jobs because that extends the time of the job run unnecessarily. One thing you could do to resolve this is detect for a environment variable (using getenv('WOOCOMMERCE_BLOCKS_PHASE') for the flag as a fallback. That way you can use that to alternatively set the flag instead of block.ini for environments like travis where we don't need to do a build step for php only tests. You can then just define the environment variable in the .travis.yml config file for the phpunit jobs.

[nerrad]

🎉 🌮 Woot! Another great pull to merge, awesome work @senadir!!!