[Create Block] Adding a --no-plugin flag to scaffold only block files.

[ryanwelcher]

What?

This PR introduces the --no-plugin flag to allow users to use the package to scaffold only block files.

Why?

Currently, there is no way to scaffold additional blocks once the plugin has been created. Being able to create subsequent blocks quickly would be very helpful.

How?

When the --no-plugin flag is added, the script skips any plugin scaffolding and only outputs the files listed in the blockTemplatesPath ( just the block files ) into folderName as defined by the template with the default being ./src. It should be noted that the script is not "aware" of its location. Calling npx @wordpress/create-block block-name --no-plugin will create a new block inside the folderNamedirectory where it's called

The slug passed is used as the directory and block name any other flags not related to package.json items should function as expected for the block, i.e namespace.

Testing Instructions

1. From the root of packages/create-block, run node index.js test to create a new plugin with a single block
2. cd into the test directory
3. Run node ../index.js my-test-block --no-plugin to scaffold a new block
4. Confirm that the src directory has the existing block files and a new directory called my-test-block that contains new block files
5. Run npm start to confirm that the build works

Screenshots or screencast

[ryanwelcher]

This PR introduces a lot of conditionals and it would be a really good idea to start abstracting out some of the functionality to make it easier to work with.

[gziolo]

This PR introduces the --block-only flag to allow users to use the package to scaffold only block files.

This is great. We really need this option to make it possible to scaffold more blocks for existing plugins ❤️

I left some comments from my testing. In general, this PR is nearly ready. It just requires some final decisions like:

• Where to exactly output the block folder?
• How to name the flag? It's probably too late to have npx @wordpress/create-block and npx @wordpress/create-block-plugin 😅 The only alternatives I can think of are --no-plugin or --skip-plugin which might be less clear.

[gziolo]

Everything works great and I'm really excited about this new feature. I left my feedback for consideration. Let's also include an example with some details how it works in the README file.

[ryanwelcher]

I found an issue while testing where if a --template was passed that didn't support the blockTemplatesPath property an assets directory was created containing the actual template files.

As a result, I have added some logic to check to see if there are block template files and if not, error out with a message.

This can be tested by using the following command from the root of the create-block package.

1. Template with support: node ../index.js my-test-block ---template=@ryanwelcher/dynamic-block-template --no-plugin
2. Template without support:node ../index.js my-test-block --template=@ryanwelcher/multiple-blocks-template --no-plugin

[gziolo]

I can confirm that the newly added check for block templates works as expected:

It makes me wonder whether we should bail out early when loading the config for the template. In effect we would have two checks:

• Show error when there is no blockTemplatesPath provided together with --no-plugin flag: The template selected doesn't support --no-plugin` option.
• If both --no-plugin and the blockTemplatesPath was provided and there were no block files loaded, we could just show the message that No block files found in the template. The template "XYZ" is incorrectly configured.

[gziolo]

Excellent work. I think it's ready feature-wise. There is only one remaining task left for the lodash support, which isn't a blocker but nice to have.

The other comment about handling edge cases is my just musing that you can ignore in the first iteration 😄

[gziolo]

gutenberg/packages/create-block/lib/prompts.js

Line 11 in 9a4b95e

'The block slug used for identification (also the plugin and output folder name):',

here we could make it more universal for the time being so it fits also the case when user passes --no-plugin flag:

The block slug used for identification (also the output folder name):

In the long run, if we were to support multiple blocks scaffolding in one go, we might want to have two distinct slug prompts - one for the block and the other one for the plugin. I'm not sure about that yet, but I wanted to flag it.

[ryanwelcher]

gutenberg/packages/create-block/lib/prompts.js

Line 11 in 9a4b95e

'The block slug used for identification (also the plugin and output folder name):',

here we could make it more universal for the time being so it fits also the case when user passes --no-plugin flag:

The block slug used for identification (also the output folder name):

I'll make this update before merging.

In the long run, if we were to support multiple blocks scaffolding in one go, we might want to have two distinct slug prompts - one for the block and the other one for the plugin. I'm not sure about that yet, but I wanted to flag it.

I LOVE this idea. It's been something that always bugged me that the plugin and the block had the same name. Being able to pass different names for the plugin would be really handy. I'll open a new issue for it.

[ryanwelcher]

related #43235