woocommerce/plugins/woocommerce-blocks/docs/blocks/feature-flags-and-experimen...

9.7 KiB

We have feature gating system setup in our plugin that defines what is accessible to the public and what is not, it has three phases:

  • Core flag WOOCOMMERCE_BLOCKS_PHASE=1: anything that is not hidden behind a flag, falls under this category, and it contains all of the code that runs on WooCommerce Core plugin.
  • Feature plugin flag WOOCOMMERCE_BLOCKS_PHASE=2: anything that is behind this flag is code that is shipped to our feature plugin, the files of blocks behind this flag are also present in WooCommerce Core, just not active.
  • Experimental flag WOOCOMMERCE_BLOCKS_PHASE=3: This flag contains things that we're not shipping yet, so unfinished work mostly. These features are only available in developer builds of the plugin.

We also use an __experimental prefix for any experimental interfaces. This is a signal to those reading our code that it should not be implemented in for production use. Currently this prefix is used in the following ways:

  • Prefixing references that are experimental. An example would be PHP action or filter slugs.
  • Prefixing functions or methods that are experimental.

Blocks behind flags

The majority of our feature flagging is blocks, this is a list of them:

Feature plugin flag

Experimental flag

Features behind flags

We also have individual features or code blocks behind a feature flag, this is a list of them:

Feature plugin flag

Experimental plugin flag

  • Inserting Product Element blocks globally from the inserter (JS flag).

Processes and commands that use a flag

  • npm run build:deploy uses the feature plugin flag (env flag).
  • travis uses the experimental flag when running tests (env flags).
  • webpack creates a blocks.ini when running (env flag).
  • webpack filters out experimental blocks when building. (env flag).
  • certain e2e tests are skipped if the environment is not met (env flag).

Usages of __experimental prefix