Today, @wordpress/create-block is too optimized for the specific use case of developing a single block as a WordPress plugin. Things quickly get more complicated when another block is needed or a custom JavaScript is integrated to extend the block editor. This issue will track necessary enhancements and bug fixes to resolve the outstanding problems that need to be addressed to streamline the experience.

Current tasks

• Create Block: Optimize the default template for multiple blocks case #68175
• Create Block: Add multi variant #67886
• Create Block: Allow external templates to customize more fields #68193
• Create Block: Support Custom Prompts in External Templates #67806
• Scripts: Recommend passing JS entry points with paths #68251
• When defining the JS and CSS assets in the block.json file, we could change the strategy. Developers, when using the source directory should only reference source files. The build process would detect them as entry points and update block.json accordingly so everything is magically configured inside the build folder.
• Improve auto-injecting the webpack runtime chunk into block.json when viewScript defined.

Plans for easier build command customization

This plan builds upon the idea proposed by @youknowriad in #66466 (comment).

So here's a proposal that may or may not be valid depending on the answer to the question above but what if we change that and require an entry point to the build command:

wp-scripts build src/index.js
wp-scripts build assets/style.css
wp-scripts build blocks/block.json

What use-cases we would be missing in this case?

I'm using examples of custom webpack configs @justintadlock and @ndiego used in their projects to explain requirements. I validated how much the new CLI syntax could remove the need to deal with webpack internals, and I got very positively surprised how quickly I could map it to the idea discussed. Here is a summary.

Blog post example

This is how the revised command could look for the config overrides included in the blog post Getting and setting Block Binding values in the Editor.

npx wp-scripts build js/editor=./resources/js/editor.js --output-path=public

I was also surprised to learn that I could run the command successfully with the current version of WP Scripts.

Note: I tried also the following npx wp-scripts build editor.js --webpack-src-dir=resources/js --output-path=public/js. However, --webpack-src-dir isn't integrated with the syntax for file paths, they are all relative to the current working directory.

Social Sharing block example

For the Social Sharing block, the command in the future would look as follows:

npx wp-scripts build ./src/*/block.json ./src/*/utils.php

Note: All paths by default would get resolved from the current working directory, so src needs to be explicitly passed to avoid the case where they end up inside build/src/*.

As of today, the following should work, too:

npx wp-scripts build --webpack-copy-php

Note: It would ensure all PHP files get copied from src to build directory. Both are considered default settings today in the default webpack config when no files are listed. block.json files get automatically detected and related JS set as entry points.

Block Visibility plugin

Another config is for Block Visibility. In the future, it could be handled with the following:

npx wp-scripts build block-visibility-editor=./src/editor.js block-visibility-setting=./src/settings.js block-visibility-editor-styles=./src/styles/editor.scss block-visibility-contextual-indicator-styles=./src/styles/contextual-indicators.scss block-visibility-setting-styles=./src/styles/settings.scss

The custom config is required today, because there is no support for CSS as entry points. This PR adds this concept. I'm not entirely sure how the file path syntax fits here. It might even work out of the box for the syntax provided above. It won't work without small tweaks for a simplified version like npx wp-scripts build ./editor.css because it assumes the extension is .js.

X3P0: Ideas theme

A more real-world example of what is necessary to do with themes. Here’s the webpack.config.js. This one is very complex as it also handles fonts and media. Something like that might work one day:

npm run build css/blocks/*/*=./resources/scss/blocks/*/*.scss js/editor=./resources/js/editor.js css/*=./resources/scss/*.scss ./resources/{media,fonts}/*.*

Important note: I don’t know how far we can go with these globs. The challenge is mostly for the part that maps the paths to entry points.