Gutenberg: Add BlockBook as an officially supported @wordpress package

[youknowriad]

Yesterday, I released BlockBook. In addition to create-block and wp-env I believe it's a great addition to the block developer and theme developer toolbox. I think it makes sense to add it as an official @wordpress/package.

It does add a bit of maintenance work to the team and contributors. So curious to hear your thoughts? @WordPress/gutenberg-core

[swissspidy]

Since it's brand new I'd probably give it more time before thinking about porting it over.

[youknowriad]

Can you clarify more, what do you think the extra time will give us that we don't know today?

[swissspidy]

More robustness, developer feedback, discussion within the team.. off the top of my head

[youknowriad]

I agree it needs to be more robust and needs to be improved but it's a development package, it can be improved iteratively like wp-env or create-block, it's not something that needs to be perfect from the start like production features.

[nerrad]

I like the package, but as a part of considering adding packages to the official @wordpress namespace (even for development packages), answering a few questions would be helpful:

• Why is this something that should be published in the @wordpress namespace?
• What demonstrable benefits does this bring not only to the Gutenberg project but also the larger WP ecosystem?
• What investment in time is required from project maintainers/contributors to maintain and develop this project?
• Are there ways in which this package can be used immediately in Gutenberg? If so, what are the plans for implementation and how does that affect other systems/processes we currently use?

Those are just a few questions at the top of mind. Riad, if this was someone outside the core team submitting a package for consideration, what criteria would you want to be met before adopting it in the project?

[youknowriad]

These are great questions and for the record, if I didn't think this package was valuable as a @wordpress package, I wouldn't propose it for Core. Keeping it under my name is rewarding for me personally but I do believe this should be "Core" and that's why I'm ok "giving" it to Core and I'm going to try to explain why I think it is.

1- Why is this something that should be published in the @wordpress namespace?

Because it's a useful tool for any third-party block developer. It allows them to build their block, test it in different themes, and offer generated documentation for their blocks.

2- What demonstrable benefits does this bring not only to the Gutenberg project but also the larger WP ecosystem?

There are a lot, here are some on top of my head.

• The first one is very simple it closes this long-standing issue #8733. Developers wanting to create templates need to know the technical names of the blocks and their attributes. The tools resolves that for Core Blocks (useful for Gutenberg project) and also solves the same issue for the third-party blocks (WP echosystem).
• Theme authors struggle to style blocks properly, they now can do that and test it quickly using BlockBook.
• Gutenberg developpers can develop and test Core blocks in isolation (block stories).

There's also a lot to be done (on the roadmap) that will push the boundaries even further:

• Block deprecations are hard to write and tests, the tool can include a built-in deprecation simulator. (You feed it markup, it gives you what deprecation was used and how it upgrades the block)
  
  
  
  • It can include other tools (block parsing, pasting...).
  
  

What investment in time is required from project maintainers/contributors to maintain and develop this project?

This is the main reason I created the issue, because any feature/tool, no matter how big the benefits are, require maintenance. The important question for me is: Are the benefits here worth it enough to add some level of maintenance. For me the answer is yes.

Are there ways in which this package can be used immediately in Gutenberg? If so, what are the plans for implementation and how does that affect other systems/processes we currently use?

Of course, as shown above this http://youknowriad.github.io/blockbook/ can be considered the official developer documentation for Core blocks. We don't have anything like that in the docs and I'm pretty sure this is very valuable.

Plans for implementation: Well, it's already implemented, we'd just have to figure out where to host it on wp.org.

[epiqueras]

It's definitely a yes for me.

[nerrad]

Thanks Riad for taking the time to answer the questions :). If anything, it helps document in the issue some rationale for adding it to the project beyond just it comes from a core team member that asserts it's value. I'd still love to hear your thoughts on this if possible:

if this was someone outside the core team submitting a package for consideration, what criteria would you want to be met before adopting it in the project?

Personally, I'm in favor of this being added as a package. I can see value from the context of the WooCommerce Blocks project where we could use this for the blocks we build. I also think it has value for other teams in the WordPress ecosystem as you outlined.

[youknowriad]

if this was someone outside the core team submitting a package for consideration, what criteria would you want to be met before adopting it in the project?

Well, I hope I'm applying the same criteria whether it's from me, another core team member, or any contributor.
For me, it comes down to answer this question I asked above:

Are the benefits here worth it enough to add some level of maintenance?

It is a very subjective question and people might think differently. I don't think there are formal guidelines we can define to answer this question, the 80/20 rule is kind of related but I don't see any objective measure of computing the added value, and I don't see what measure we can apply to "maintenance" either. It comes down to trust in the judgment of the Core developers making the decision. I do trust Core developers to try their best to make the same judgment no matter who proposes something.

Obviously, I built this thing so I think it has a very high value, but because it's me, I'm biased and that's why I opened this issue to ask everyone to give their opinion about this question.

[mtias]

+1 for adding this. It'd be good to get a sense for how all the dev tools are to be considered as we run the risk of fragmenting the toolset too much. This is also something that i think we should look at integrating with the block directory eventually.