Proposal: Modern Dev Tooling
The goal behind creating this proposal document is to help convince the WordPress community, core developers, and especially the contributors behind the all-new Twenty-Nineteen default WordPress theme to use developer build tooling. Which in turn will help modernize
I'm a full-time open source dev with hundreds of developer-tooling related FOSS (Free & Open Source Software) projects, one of which is most relevant to this proposal — it's called create-guten-block. Investing in better developer experience and dev-tooling for WordPress developers in the post-Gutenberg world is vital.
The create-guten-block is used by ~200 Gutenberg WordPress plugins on the WordPress.org repo (As per my knowledge, that is 90% of the total plugins using Gutenberg on WP.org). CGB has about ~1500 Stargazers/forks and has been downloaded 100,000+ times.
The reason to share this context and the stats is to make a point that developers need to have better tooling at their disposal for not only a better development experience but also building plugins/themes based on Gutenberg with high-quality code. These stats are a testament towards the need of such tooling.
For years, default themes have been the source of truth for many new developers, so it's my recommendation that we start Twenty-Nineteen default WordPress theme with developer build tooling in place. It will be beneficial for the WordPress community in many ways, some of which are listed below:
🗃️ MODERN CODE
- WordPress will have a modern code base
- Offline support for WordPress themes will lead to 10x better UX
- The possibility of a modern code base with PWAs, Web/Service Workers
- Make it easier to transition towards a more modular code for WordPress Core
🏇 FASTER WEB
- WordPress is 32% of the meaningful web at the moment
- Build tools, i.e. webpack will help make 32% of web faster
- JS tree-shaking, removal of unused CSS, optimized mobile sites — all big wins
🌟 QUALITY CODE
- Build tooling can help add ESLint & Prettier to the mix
- ESLint/Prettier + other linters help improve code quality
- Build tools make it easier to use standard coding best practices
- Modern code testing, coverage, deployment, and semantic versioning tools
🦁 DEVELOPER EXPERIENCE
- Developer tooling will help improve the DX (Developer Experience)
- Generally, all build-tools (if used the right way) make developers happy
For the development of Twenty-Nineteen default WordPress theme, I suggest the inclusion/building of following dev-tools:
ESLint— Code linting and error reporting
Prettier— Code reformatting as per set standards
phpcs- PHP Code Sniffer to uphold WP PHP Code Standards
phpcbf- PHP Code Beautifier and fixer comes with
create-guten-block— Sane defaults #ZeroConfig Gutenberg starter kit
It's expected to have some sort of backlash towards this proposal so, I am going to keep a log of frequently asked questions and their answers.
❓ Are you suggesting we build custom blocks inside a WordPress Theme?
NO. I never said that. Since the day I built create-guten-block I have been preaching the same lesson,
Custom blocks should only be built inside plugins. Yes, blocks go in plugins.
And in this case I am suggesting that we build a TwentyNineteen Companion plugin to showcase how we can extend WordPress with custom blocks. WordPress is a CMS and for building custom blocks we'll need companion plugin with the theme. That plugin should have a build tooling process to it.
Default themes used to do that. TwentySeventeen has custom pages and customizer helped. With TwentyNineteen we can showcase custom blocks as well. Developers look at default themes to derive inspiration for their work.
That's what I am recommending.
❓ TwentyNineteen should be kept simple!
Sure, it should be. But there's an opportunity here that can be explored. If we built Gutenberg to only build simple CSS only WordPress themes without showcasing what custom blocks are now capable of — then we just wasted two years for nothing.
I get the idea that there should be a simple theme to showcase simple things. But there can easily be a companion plugin to showcase how to extend WordPress with Gutenberg and improve your dev experience with dev tooling.
NOTE: I think all of the custom blocks related code should probably go in a companion plugin for this theme. That has always been the general consensus and my recommendation to fellow developers.
For further discussions I have opened up this issue on the TwentyNineteen repo →