Tweak Experimental Flag feature gating to allow for holding back from WC core.

[nerrad]

While we do currently have feature gating in place for features in the blocks plugin, it's just a binary flag. This means that anything we choose to expose on releases of the plugin, will also get release if that tag is included in WC core.

However, I can see the use case where we may want things only available in the plugin and not in what gets bundled with WC core (for instance giving the Cart and Checkout blocks some extended time in the plugin before bundling with WC core).

So this issue is for implementing improvements to the feature flag system so that we can select what "stage" a feature is (i.e. only dev, plugin only, everywhere).

[senadir]

This means we should probably switch to a numbered system, moving experimental to 3, stable to 2, and core to 1, Cart and Checkout blocks can live behind 2 and our condition will be

if ( WOOCOMMERCE_BLOCKS_PHASE > 1 ) {
    doStableButNotCoreStableCode();
}

Gutenberg advises against this, are we going to hit a similar issue? if we keep our gate in the plugin core code only (and not in published npm code) we will probably not hit this issue, and we have some code in place to prevent WOOCOMMERCE_BLOCKS_PHASE from being undefined, so unless WooCommerce builds our plugin, this shouldn't be an issue.

Why should I only use === or !== when comparing process.env.GUTENBERG_PHASE and not >, >=, < or <=?

This is a restriction due to the behaviour of the greater than or less than operators in JavaScript when process.env.GUTENBERG_PHASE is undefined, as might be the case for third party users of WordPress npm packages. Both process.env.GUTENBERG_PHASE < 2 and process.env.GUTENBERG_PHASE > 1 resolve to false. When writing if ( process.env.GUTENBERG_PHASE > 1 ), the intention might be to avoid executing the phase 2 code in the following if statement's body. That's fine since it will evaluate to false.

[nerrad]

if we keep our gate in the plugin core code only (and not in published npm code) we will probably not hit this issue, and we have some code in place to prevent WOOCOMMERCE_BLOCKS_PHASE from being undefined, so unless WooCommerce builds our plugin, this shouldn't be an issue.

I think I agree here. Gutenberg is slightly different in that the gating is published with packages which then are built in WordPress core (where there could be issues). However, we publish the built plugin in WordPress core and we have a slightly different way of handling things php side as well.