Skip to content
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

Add BlockBook as an officially supported @wordpress package #24152

Closed
youknowriad opened this issue Jul 23, 2020 · 11 comments
Closed

Add BlockBook as an officially supported @wordpress package #24152

youknowriad opened this issue Jul 23, 2020 · 11 comments
Labels
Needs Decision Needs a decision to be actionable or relevant npm Packages Related to npm packages [Type] Build Tooling Issues or PRs related to build tooling

Comments

@youknowriad
Copy link
Contributor

youknowriad commented Jul 23, 2020

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

@youknowriad youknowriad added [Type] Build Tooling Issues or PRs related to build tooling npm Packages Related to npm packages labels Jul 23, 2020
@swissspidy
Copy link
Member

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

@youknowriad
Copy link
Contributor Author

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

@swissspidy
Copy link
Member

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

@youknowriad
Copy link
Contributor Author

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
Copy link
Contributor

nerrad commented Jul 23, 2020

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
Copy link
Contributor Author

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 Create self-documenting block documentation for developers #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
Copy link
Contributor

It's definitely a yes for me.

@nerrad
Copy link
Contributor

nerrad commented Jul 23, 2020

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
Copy link
Contributor Author

youknowriad commented Jul 23, 2020

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
Copy link
Member

mtias commented Aug 25, 2020

+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.

@youknowriad
Copy link
Contributor Author

At this point BlockBook is kind of outdated, I do think we need a dev tool like that on Core and for plugins. But I'm closing this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Decision Needs a decision to be actionable or relevant npm Packages Related to npm packages [Type] Build Tooling Issues or PRs related to build tooling
Projects
None yet
Development

No branches or pull requests

6 participants