Should the WordPress/create-block package be renamed?

[bacoords]

I'm a huge fan of the wordpress/create-block package and all that it's enabled, but I think we need to address the fact that these days, it only sometimes is used to create blocks.

Often it's just the fastest way to scaffold a new WordPress plugin that leverages the wp-scripts build process, dependency extraction, etc. It's sort of a more modern take on the wp scaffold with the extra power of not needing any previous software installed to run (other than node).

So I think we should have a discussion around renaming it. Something like @wordpress/create ? ("Drop the block. It's cleaner") The default can still be creating a block plugin, or maybe the default could be a new site using something like playground cli or wpnow.

Overall, the idea is having one command for spinning up any new WordPress code you might need:

# Maybe the default is a blank site w/ Playground
npx @wordpress/create my-new-site

# Create a block
npx @wordpress/create -t block my-new-block

# Create something from a custom template
npx @wordpress/create -t some-org/some-template-repo my-new-plugin

Disclaimer: I don't actually know what is involved in changing a package name. I'm sure there'd need to be some way for the old npx commands to still work without failing, maybe just passing the parameters on properly to the new package, but hopefully someone smarter than me can chime in.

[courtneyr-dev]

I don't have strong opinions, but did also consider that thought should be given for how Create Block Theme is also in use. Naming things is hard.

[bacoords]

Yep and you know we love renaming things in WordPress!

[troychaplin]

I really like the direction you're thinking in, especially around broadening the scope of the tool beyond just block scaffolding.

That said, I’m not sure about making Playground the default. I haven’t really dove into it yet, so that might just be due to my lack of experience with the tool speaking. Still, I love the idea of using flags or templates to define what you want to scaffold, whether that’s a block, a plugin, a theme, or even a Playground-based project.

My primary use case has been using @wordpress/create-block with the --no-plugin flag, since I mostly build multi-block plugins. It would be great to see direct support for that kind of setup, maybe something like a --multi-block flag that scaffolds multiple blocks within a shared plugin structure.

One thing I find limiting is that there’s no option to scaffold just a plugin, something that sets up the modern build tools like wp-scripts, but without including a block. I don’t reach for this often, but it would be great to have a supported option for that use case, rather than having to manually remove the block files each time.

All that to say, I love the script and use it constantly, but I’d be really excited to see it evolve into something even more flexible. Glad you’re kicking off this conversation!

[ryanwelcher]

One thing I find limiting is that there’s no option to scaffold just a plugin, something that sets up the modern build tools like wp-scripts, but without including a block. I don’t reach for this often, but it would be great to have a supported option for that use case, rather than having to manually remove the block files each time.

This is now technically possible using a variant and passing null to the blockTemplatesPath variable in the definition. There will still be a block.json file generated but it gets you a bit closer.

[bacoords]

Yep I tried adding rm block.json as a postinstall script but didn't realize lifecycle scripts didn't work. Looks like there's a PR for that, though!

Bigger picture, maybe a --no-block flag would be nice? I'm not sure. The point of this discussion is to rethink of it from a broader perspective instead of adding more one-off flags.

My primary use case has been using @wordpress/create-block with the --no-plugin flag, since I mostly build multi-block plugins. It would be great to see direct support for that kind of setup, maybe something like a --multi-block flag that scaffolds multiple blocks within a shared plugin structure.

This would make a great variant. And then often in my multiblock plugins I include a "create-block" script in my package.json that you can use to scaffold additional blocks, but with the namespace already entered, etc (example)

[gziolo]

It would be great to see direct support for that kind of setup, maybe something like a --multi-block flag that scaffolds multiple blocks within a shared plugin structure.

I started some work on that front a few months ago. It’s tracked in an issue:

• Create Block: Streamline experience for working with multiple blocks and shared assets #68190

There is still a lot of improvement necessary but it’s all doable if we discuss it further and get folks involved.

[gziolo]

Some of the conversations that helped to evolve the scaffolded project with a plugin and multiple blocks happened in this old issue:

• Create Block: Create a more modular structure that is easier to extend to several blocks #25188

[bacoords]

It would be great to see direct support for that kind of setup, maybe something like a --multi-block flag that scaffolds multiple blocks within a shared plugin structure.
I started some work on that front a few months ago. It’s tracked in an issue:

I wonder if this could more easily be solved with a variant now that variants are easier to be modified with different plugin / block template paths.

[ryanwelcher]

From a philosophical point of view, the idea of having this package create anything that is needed by a developer is 🔥.

I think that leveraging the templating system is how this can be achieved. What if we didn't need pass flags to the tool that defined what parts of the template were output but rather --template dynamic-block-files or --template block-theme-starter and the templates defined what is being created and where?

From a technical point of view, there will need to be some work done to decouple some of the steps that are run that are directly related to creating blocks (i.e automatic generation of a block.json file). We'd also need to define what the baseline would be from a files/setup point of view. Maybe is just keeps doing what it does now and creates a static block?

If we make this tool implementation agnostic and allow the template to define what is being created (with backwards compatibility in mind) I think it becomes the tool that can do anything that is needed.

[gziolo]

It’s something that was discussed previously in other places. It’s definitely worth emphasizing that there has been growing appetite to go beyond scaffolding a single block:

• Create Block: Create a more modular structure that is easier to extend to several blocks #25188
• Create Project package - scaffold necessary ingredients to work with an existing block #59759
• Create a @wordpress/create-project package to scaffold scripts and styles #23514

I shared the following before which is still relevant also in this discussion:

I would rather extract common logic from it into @wordpress/create-plugin that would cover all other cases like registerPlugin usage or creating a standalone block editor.

If that happens, @wordpress/create-block could use predefined templates for creating blocks but the scaffolding logic should rather be moved to the new package/tool. It might require making the existing CLI more flexible.

I followed up later with:

Now that it’s possible to scaffold the plugin shell independently of the block when using @wordpress/create-block, it should open ways to implement this proposal without too much code duplication.

Then later, I said:

I have recently started thinking about themes, too. It's another place where folks use WP Scripts to manage JavaScript and CSS files that require the build step. Consequently, we should consider creating a general-purpose package @wordpress/create-project that would contain most of the logic that @wordress/create-block contains today.

---

So as you can see, we are in full alignment in the terms of what should be possible. The only slight difference I would suggest is we keep also the existing package focused on creating blocks and make another one that can scaffold everything folks need for WordPress development.

I think we would also need to improve @wordpress/scripts so it can successfully process assets in any project. A related proposal is here:

• Create Block: Streamline experience for working with multiple blocks and shared assets #68190

[bacoords]

Consequently, we should consider creating a general-purpose package @wordpress/create-project that would contain most of the logic that @wordress/create-block contains today.

That makes a lot of sense to me as well. There'd be a lot of overlap, but it's true that a new package makes more sense.

Ideally, from a developer standpoint, it would be great to have some composable options/flags to be able to run additional commands to add specific features either when starting a project or later when modifying it.

• block editor plugins (sidebars, etc)
• block attributes/extensions, like additional inspector controls with corresponding render_block filters
• block styles
• block patterns
• admin screens
• CPTs
• blocks (perhaps leveraging --no-plugin in the create-block package)

All of this would mean a very opinionated file structure.

[t-hamano]

The latest version of Gutenberg has a new build system for WordPress plugins called @wordpress/build.

https://github.com/WordPress/gutenberg/blob/trunk/packages/wp-build/README.md

It has been proposed that this build tool should be able to auto-detect and auto-register blocks. Please let us know your thoughts.

#74542