Create a @wordpress/create-project package to scaffold scripts and styles

[leoloso]

Is your feature request related to a problem? Please describe.
Package @wordpress/create-block scaffolds single-block plugins. However, not everything in Gutenberg must be dealt with through a block.

For instance, any panel component, such as PluginDocumentSettingPanel, must be registered through a regular script, not through a block.

Currently, in order to scaffold the script for a panel component for my plugin, I do the following steps (documented here):

1. Create a single-block plugin using @wordpress/create-block
2. Modify the generated PHP file, to register a regular script instead of a block

This way, I can use the webpack configuration from @wordpress/scripts. However, this process is cumbersome, error-prone, and unnecessary.

Describe the solution you'd like
It would be much better to already have a scaffolding tool similar to @wordpress/create-block to create single-script plugins.

Talking to @gziolo he suggested to name it @wordpress/create-ui-plugin

[gziolo]

Firs, I'd like to make it clear that PluginDocumentSettingPanel exists mostly for backward compatibility and it wasn't designed as a primary way to extend the block editor. See #3330 with the extensibility overview.

Talking to @gziolo he suggested to name it @wordpress/create-ui-plugin

Given that we have @wordpress/create-block that is a very specialized scaffolding tool that aims to make it simple to create blocks, mostly to support the needs of Block Directory, 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.

[mrleemon]

I'm using PluginDocumentSettingPanel in a plugin to add a panel with some meta fields from a custom post type to the document panel. If PluginDocumentSettingPanel exists mostly for backward compatibility, how are we supposed to add panels to the document panel? As the meta fields are a very important part of my custom post type, I don't want them to be hidden behind a cumbersome plugin sidebar. Any alternatives?

[gziolo]

@mrleemon, first, I would restrain from criticizing work of a group of contributors that volunteer to the project. Every project is different and extends WordPress in a different way.

I also didn’t say you shouldn’t be using the API you mentioned. @ryanwelcher added it earlier this year based on recurring requests from plugin developers. I just don’t think it should be the highlighted example in the scaffolded plugin.

[ryanwelcher]

@mrleemon as @gziolo mentioned the introduction of PluginDocumentSettingPanel was in response to the exact need you're explaining. There was no equivalent to add_meta_box available to plugin/theme developers so adding any custom panels always placed them at the very bottom of the admin experience or the bottom of the document sidebar.

As the project moves forward, I'm sure there will be a more elegant solution presented to extend the editor experience but for now, go with the API.

If there is something that you'd like to see, I would encourage you to open an issue/PR.

[mrleemon]

@mrleemon, first, I would restrain from criticizing work of a group of contributors that volunteer to the project. Every project is different and extends WordPress in a different way.

Sorry

@mrleemon as @gziolo mentioned the introduction of PluginDocumentSettingPanel was in response to the exact need you're explaining. There was no equivalent to add_meta_box available to plugin/theme developers so adding any custom panels always placed them at the very bottom of the admin experience or the bottom of the document sidebar.
As the project moves forward, I'm sure there will be a more elegant solution presented to extend the editor experience but for now, go with the API.

Thanks for the clarification

[leoloso]

Possibly the script must be registered on the footer. See #23607

[gziolo]

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.

It could be beneficial addition knowing we maintain today more examples of JS-based packages enriching WordPress.

[flexseth]

Something I've been interested in, came across the issue and wanted to cross-link my request

• Create Project package - scaffold necessary ingredients to work with an existing block #59759

[ryanwelcher]

It is possible to create a template that create-block can use to scaffold non-block functionality such as registering a slotfill, variation etc. I would encourage you to try that approach to see if it fits your needs. You would be able to leverage variations and the mustache conditionals to output the files you need.

Have a look at this template I am using to do exactly that. I have a variation (called plugin) that scaffolds what I need for non-block functionality.

[gziolo]

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. Just to give an idea, today when creating the custom template as shared by @ryanwelcher in the previous comment, you have to define directories with templates for the plugin and the block:

{
    pluginTemplatesPath: join( __dirname, 'templates/plugin' ),
    blockTemplatesPath: join( __dirname, 'templates/block' ),
}

There could also be themeTemplatesPath introduced in the future. By making these paths optional, we could much easier to decide what mix of elements should be scaffolded by the project:

• block
• theme
• theme + blocks
• plugin
• plugin + blocks

[ryanwelcher]

I'd love to see tools like create-block for anything extenders need. I have an experiment for a theme tool that is based on create-block that we could use to experiment. It was pretty straight forward to put together as it's basically all of the internals of create-block with modifications for themes.

https://github.com/ryanwelcher/theme-cli-tool

Perhaps the approach is to abstract the internals of create-block, scaffolding engine and template system into a package that can power any kind of tool?