WordPress offers a @wordpress/scripts package that allows plugins to build JS heavy plugins (and themes) easily. The premise is that it’s opinionated enough to the point that developing for WordPress becomes easy or feels simple.

The premise is good, that said, right now it’s underperforming. We unfortunately fell in the gap of “flexibility” which basically meant complexity for everyone. This lead to decisions like: Webpack strong dependency, complex flows and unclarity. It’s also telling that Gutenberg internally uses wp-scripts on the surface only, the packages are built with other custom tooling.

I think there’s a path forward to solve that though. What if there’s instead of flexibility, we absorb complexity into the tool to make plugin development as easy as it should have been, you want a new page, in wp-admin, just add a folder with index file for that page, you want a new block, just add a “blocks” folder with a list of blocks, you want a new pattern, it’s the same, you want to build a reusable components package that you can leverage in the other places, just add a package into a packages folder… But the build command is always the same wp-scripts build no arguments, nothing, the flexibility is in what it can accomplish (auto-discovery and conventions) not in how you tweak the configuration of the bundling or styling… It’s all decided for you, you just focus on the features you want to build.

Can you imagine how unified and powerful plugin development can be. Developers stop thinking about how to “glue” things together, instead they only focus on building what’s meaningful to them.

How do we get there?

This idea is both ambitious but at the same time, not so much because the tools are already here, we need to provide them in the right way. So maybe before offering a public API for this, we start by leveraging Gutenberg itself, bringing benefits of this idea to Gutenberg itself. How can we update Gutenberg tooling to build the full project “without config”. How can we arrive to the idea of a single command that discovers what needs to be built from the content of the folder/plugin itself. Gutenberg is package heavy so we can focus on that part first: how to automatically build packages into WordPress scripts or WordPress script modules without actually writing any single line of php.

Buidling a single package

The first step is going to be, to pick one package, example dom package, picked randomly. We know that for this package we want the following output:

• Build the package itself without bundling (create the build folders) because this is a package that can ship to npm.
• Bundle the package into a single script file that defines the wp.dom variable.
• A php file that registers that bundled file as a WordPress script.

So this first step could be:

1- Mark this package with a flag “wpScript” : true (in fact we already have this) to indicate that it needs to be built as a script.
2- Mark it using a temporary flag “wpScript2”: true or something to indicate that we’re going to use it as a test ground for the new build command.
3- Write a build script /bin/build-package or similar that can perform the steps above.
4- Exclude the packages marked “wpScript2”: true from our current scripts (webpack…)

Maybe that build command can use new tools (esbuild or else) that are faster than our babel and webpack tools (very slow). I think today’s tech is way more interesting and is ready to take over.

Expanding

Once we have the command working for a single simple package, we can start expanding it to absorb more use-cases:

• We have packages that register both a script and a style.
• We have packages that register multiple styles and scripts (exports config in the package?)
• We have packages that don’t register any script (bundled package), so we only need to build the package in this case and not bundle it.
• We have packages that don’t register any script but we need to bundle and register a script module.

In this step we’ll also need to remove some of the existing custom babel plugins that we have (JSON one for instance, JSON imports are now supported by all browsers and are a valid JS syntax)..

At the end of this step as well, we should be able to remove our custom scripts and configs that are Gutenberg specific and we could start thinking about making our new “build” script as part of the @wordpress/scripts package itself to make it available for all plugins.

The real power

All the above was preparation work, I’m more excited about what it could unlock from a DevX perspective now that we reached a stage where we have a single opinionated flow to build plugins:

• Think about WP-Admin pages that are auto registered because you have a pages folder in your plugin, these pages can leverage any wordpress package (be it a script module or a script) automatically or even internal packages in your own “packages” folder.
• Think about Fields that are auto registered and added to DataViews… just because you have a fields folder in your plugin.
• Think about patterns or blocks that are auto-built and registered in the same way. (PHP first and augmented in JS if needed)