-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extensions: add a new option to deliver an "Experimental" subset of blocks. #14104
Conversation
This will allow one to get a different list of extensions based on different parameters: - plugin active - constant - filter
We now build 3 bundles: - The default production bundle with just the production blocks. - The experimental bundle with production blocks as well as experimental blocks. - The beta bundle with all the blocks: production, experimental, and beta.
- When using the experimental variation, we need both prod and experimental blocks. - When using beta blocks, we need all blocks.
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: January 14, 2020. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all works well with virtually all documentation suggestions. Once the confirmation text on the CLI command is updated at least, ready to merge.
...presetProductionBlocks, | ||
..._.get( presetIndex, [ 'experimental' ], [] ), | ||
]; | ||
const presetBetaBlocks = [ ...presetExperimentalBlocks, ..._.get( presetIndex, [ 'beta' ], [] ) ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, when I hear "experimental", I think almost like it is "alpha" code and so seeing that experimental blocks are included in beta at first feels like the opposite of expectation.
With the block set meant to roll on special platforms (e.g. our Atomic infra), it makes sense since we don't want to roll beta out to them.
If there isn't a better word other than experimental, let's be very explicit that beta blocks includes experimental everywhere we discuss the concept or the constant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, "experimental" may not be the best word for it. That's all I could come up with though :\
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all works well with virtually all documentation suggestions. Once the confirmation text on the CLI command is updated at least, ready to merge.
Also, in thinking about this as a set of blocks expecting the latest version of WP and/or the Gutenberg plugin, should we just call a spade and a spade and check for that? Ensure the latest version of Gutenberg is installed (as a MVP we can hardcode the version and document that it should be bumped as new code is merged) before loading the experimental set? Since the beta package would have the same requirement, do we need to do that? Or is that something that we document is the expectation (beta or experimental blocks expect Gutenberg and expect it to be kept up to date?) |
Thanks for the updates! I'm good with this, so merge when you're happy! |
This was my first thought as well, but I ended up rollbacking based on our discussion in #14104 (comment) I am happy to take a third approach though: have experimental blocks enabled if you use the constant AND the latest version of WP AND the latest version of Gutenberg. This way we wouldn't have to take any extra precautions when working on those blocks? I'll merge this for now and we can iterate later. |
Caution: This PR has changes that must be merged to WordPress.com |
Sounds good. I don't have a dog in the fight, just want to be sure we're setting the stage right if those blocks realistically are expecting latest Gutenberg. |
Follow-up from #14104. In some environments (like on WordPress.com), it may be easier to use a filter to change the way we load blocks.
Follow-up from #14104. In some environments (like on WordPress.com), it may be easier to use a filter to change the way we load blocks.
Changes proposed in this Pull Request:
We currently have 2 options when building and loading Jetpack blocks in the editor:
- Production blocks
- Beta blocks (loading production blocks and a small set of Beta blocks), available when using the
JETPACK_BETA_BLOCKS
constant.This PR introduces a third option, aka variation, named "Experimental". This option loads both production blocks and a set of experimental blocks. It is automatically enabled if you use the Gutenberg plugin or the Full Site Editing plugin on your site. In practice, that would make that option available on all Atomic sites right away. The option can also be used when you don't use those plugins, via the
JETPACK_EXPERIMENTAL_BLOCKS
constant.Is this a new feature or does it add/remove features to an existing part of Jetpack?
cc @dereksmart @kraftbj since we recently discussed different options.
Testing instructions:
define( 'JETPACK_BETA_BLOCKS', true );
to your site'swp-config.php
file and make sure you can still see all blocks, including the Pinterest block (currently in Beta).define( 'JETPACK_EXPERIMENTAL_BLOCKS', true );
to your site'swp-config.php
file and make sure you cannot still see the Pinterest block (currently in Beta).yarn docker:wp jetpack scaffold block jeremy --variation="experimental"
to create a brand new block.yarn build-extensions
to build that new block.experimental
subset inextensions/index.json
Proposed changelog entry for your changes: