Thus far, we've experimented with various build systems and are currently using Webpack. It's the big player in town and is something that's likely going to be used by many people who are building custom Gutenberg blocks.
With that said, we need to decide what's right for this theme.
And, I fully expect there to be forks of this theme with build systems that are suited to individual theme authors. However, I want to have a good base for the majority of theme authors who might not want to delve into all that and just needs something that works.
Defining our needs for assets
The biggest thing we've lacked is a list of actually what our needs are as theme authors to guide us each step along the way. How can we know which tools are needed if we don't clearly define what we're trying to accomplish?
CSS
CSS is the primary asset type in building WP themes. I think we have a pretty clear picture of what we want to do:
- Write in Sass and/or next-generation CSS. transpiling
- Bundle smaller files into one final file. bundling
- Our code checked for errors. linting
JS
- Write in modern JS and have it work cross-browser. transpiling
- Bundle smaller files into one final file. bundling
- Our code checked for errors. linting
Images and SVGs
- Have these files cleaned up and minimized for performance.
How the process should work
The underlying tools (whether it be Webpack, Gulp, Grunt, or something else) shouldn't really matter to theme authors. The theme should define some npm-scripts
commands that handle that.
For me, personally, I feel like I want the following things:
// Build everything.
npm run build
// Build only scripts|styles|images|svgs
npm run build:*
// Lint scripts|styles
npm run *:lint
// Watch
npm run watch
// Watch scripts|styles
npm run watch:*
That's a bit of a hierarchy. build
handles everything below it and so on.
For those that do want to or must edit
We'll have a base of standard things. However, theme authors will inevitably need to edit something in the build process. That should be simple and not require you to jump through any hoops.
For example, if a theme author needs to add a new stylesheet to be compiled separately, they shouldn't have to import that into something else. They should have a "config" file to define it (or have it done automatically). Same thing with JS files.
That means having a clear organizational structure (I like where we're at right now with this) and having clear docs (we'll get those).