Eightshift Boilerplate is a WordPress theme skeleton that runs webpack and Tailwind in the same repo

A theme skeleton with a front end build attached

Eightshift Boilerplate is described as a modern, Gutenberg-oriented WordPress theme boilerplate, and the repository description puts it more plainly: it contains all the tools you need to start building a modern WordPress theme, using all the latest front end development tools.

The framing is what makes it different from a starter theme. A starter theme gives you a theme and you edit its PHP and CSS. This gives you a theme, a front end build pipeline, a component library and a set of conventions, and it is explicitly at the core of the Eightshift Development Kit, with the rest of the kit documented on eightshift.com.

The requirements list is where the design shows. You need PHP 8.3 or newer, Node LTS, Composer, git and WP-CLI. That is a real toolchain rather than a theme you can upload over FTP, and the presence of WP-CLI in the list tells you the workflow is command line from the start.

The project is MIT licensed, with the README saying it is free software and may be redistributed under the terms specified in the LICENSE file. It is maintained and sponsored by Infinum, and the homepage is eightshift.com.

The repository is not archived, the last push was on 2026-10-13, and the releases are 14.0.0 from May 2026, 13.0.0 from January 2026 and 12.0.0 from June 2024. So the major version moves roughly once a year and the toolchain underneath it moves with it.

The front end build, with Tailwind 4 and webpack

The JavaScript side of the repository is small and specific, and the package.json tells you what it is.

The build is webpack. The start script runs webpack in watch mode in development, and build runs webpack in production mode. The JavaScript dependencies are minimal: webpack and webpack-cli as dev dependencies, and husky and lint-staged alongside them.

The interesting part is the two Eightshift packages. @eightshift/frontend-libs-tailwind at version 3.2.0 and @eightshift/ui-components at version 7.3.0 are the project's own front end libraries, and they are where the shared component set lives. Alongside them sit @tailwindcss/postcss and tailwindcss both at 4.3.0, plus colorjs.io, glob and use-sync-external-store.

So the styling is Tailwind 4, processed through PostCSS, and the components come from a shared package rather than from code you write. That is a meaningful architectural choice: the theme and the design system are separated, and the design system can be updated independently of your theme.

The repository top level reflects the same shape on the PHP side. There is a src/ directory, the classic WordPress theme entry files footer.php, functions.php, header.php and index.php, style.css and tailwind.css, and the configuration files for each tool: webpack.config.mjs, postcss.config.js, eslint.config.mjs,.stylelintrc,.prettierrc,.swcrc, phpcs.xml.dist, phpstan.neon.dist and rector.php.

That last one is unusual enough to notice. Rector is a tool that rewrites your code automatically to modern idioms and upgrade paths, so the boilerplate does not just lint your PHP, it migrates it.

Linting, static analysis and the pre-commit hook

The quality tooling is the clearest signal of what kind of project this is, because a WordPress theme rarely carries this much of it.

On the JavaScript and CSS side there are two separate lint scripts, lintStyle running stylelint across the CSS and lintJs running eslint over src/, and a lint script that chains them. The formatter is Prettier, configured through.prettierrc.

On the PHP side there are three distinct tools. phpcs.xml.dist is the PHP_CodeSniffer configuration, which is how WordPress projects historically enforced the WordPress coding standards. phpstan.neon.dist is PHPStan, static analysis. And rector.php configures Rector for automated code rewriting.

The lint-staged configuration ties it together on a per-extension basis, running the JavaScript lint on JavaScript files, the CSS lint on CSS files, and composer test on PHP files. So every commit gets the checks that apply to what it touched.

Husky is a dev dependency, and the prepare script installs it. That means the hook setup is part of the repository rather than something each developer wires up locally, which is the difference between a convention and an enforced one.

The.swcrc file is a small but telling detail. SWC is the compiler that webpack can use instead of Babel, and having a configuration for it in a WordPress theme template suggests the build was set up with fast transformation in mind rather than added later.

The Composer side, and the copyleft choice

The PHP dependency story is in composer.json and composer.lock at the top level, and the lockfile being committed is the point. A theme with a lockfile means the same dependency versions install on every machine and in CI, which is what makes a design system upgrade reproducible rather than a surprise.

The other thing in the top level is strauss.phar, a PHAR archive checked into the repository. Strauss is a tool for vendoring and prefixing third party PHP dependencies so they cannot collide with the versions loaded by WordPress itself, which is a real problem for plugins and themes that ship libraries.

There is a CHANGELOG.md at the top level, and a .github/ directory. There is also a .prettierrc, a .stylelintrc and a .swcrc, which we have already covered.

On the licence, there is a small inconsistency worth resolving early. The README says the boilerplate is free software and may be redistributed under the terms specified in the LICENSE file, and the licence field in the repository metadata is MIT. The LICENSE file is LICENSE.md. So the terms are MIT, but they are expressed in a file whose name does not say so, and the README phrasing points you at the file rather than naming a licence. If your organisation has a policy that reads the licence field, this is the kind of detail that turns into an email later.

Where the documentation actually lives

The README is short, and that is because the documentation is elsewhere.

For getting started, the README points at the documentation on Eightshift Docs with a link to the theme getting started page. For the wider kit, the README says the Eightshift Development Kit comes with comprehensive documentation on eightshift.com.

The practical consequence is that the repository you clone is not the place you learn the project. You need the docs site, and specifically the theme section of it, to understand how the boilerplate is meant to be used.

The same applies to help. The README says to open an issue on GitHub for questions and problems, asks people to follow the code of conduct when submitting issues or participating in development, and asks them to fill out the issue template properly, with a note that doing so helps them answer issues quickly.

That last part is worth taking seriously rather than skipping. The repository is a boilerplate with conventions, and the issues are where the conventions get explained to people who arrive from a different background. A well written issue with a filled template is not just politeness, it is the mechanism by which the maintainers communicate the intended pattern.

The one thing the repository does tell you on its own is the maintainership. Eightshift Boilerplate is maintained and sponsored by Infinum, which tells you who to look at when you need a decision made rather than an answer.

Where Eightshift Boilerplate is the wrong choice

Three cases, and the first is the most common.

If you are building one small site with a custom template, this is the wrong shape of tool. The value here is the combination, a modern front end build, a shared component library, several layers of static analysis and a set of conventions. None of that pays for itself on a brochure site, and the PHP 8.3 floor, the Node toolchain and the command line workflow are all costs you take on for a result you could reach with a classic theme and a page builder.

The second is a team that does not want the conventions. The boilerplate encodes decisions, a Tailwind 4 setup, a particular component set, a particular way of structuring src/, and an opinion about how the front end is built. If your developers would rather write their own SCSS and their own block patterns, you are going to spend the first weeks removing things, which is the opposite of what a boilerplate is for.

The third is the coupling to the wider kit. The boilerplate is at the core of the Eightshift Development Kit, and the shared components come from versioned npm packages that Infinum publishes. That is a good arrangement if you are building a family of projects on one design system. It is a dependency on somebody else's release cadence if you are not, and the major version bumps, 12.0.0, 13.0.0 and 14.0.0 in the space of two years, are the release cadence you would be tracking.

The CHANGELOG.md in the repository is the place to check that before an upgrade, and reading it will tell you how much of the front end stack moves with each major version.

Editorial conclusion

Adopt Eightshift Boilerplate if you build WordPress themes for a team that wants a modern front end toolchain and a shared component library inside the theme repo, and you are prepared to learn the Eightshift conventions. Do not adopt it for a single small site with a custom template, since the toolchain and the conventions cost more than a classic theme. Before you start, confirm your hosting runs PHP 8.3 or newer, read the getting started documentation on the Eightshift docs site, and check the CHANGELOG.md before upgrading, because the project ships major version bumps that move the front end stack.

Frequently asked questions

Official sources

1. infinum/eightshift-boilerplate on GitHub
2. License: MIT
3. Project website
4. README
5. Releases