air-light, a WordPress starter theme built on Parcel instead of a build step you did not choose

What air-light is: _s with a build pipeline attached

air-light is a WordPress starter theme from Digitoimisto Dude Oy, a boutique digital agency in Jyväskylä, and it is best understood as a fork of Automattic's Underscores theme with a modern front-end toolchain bolted on.

The relationship to `_s` is close enough that the README describes a policy rather than a coincidence: most of the changes in `_s` are implemented as soon as they are committed upstream. So Air is not a static fork that has drifted. It tracks the parent theme, which means upstream WordPress starter improvements arrive without anyone porting them, and it means the template hierarchy and the PHP conventions are the ones WordPress documents rather than something the agency invented.

The mission statement is unusually specific, and it reads as a list of things the theme refuses to do. It will not implement its own wrappers or functions, it will not use templating languages that take things further from traditional PHP or CSS, and it will contain nothing that people will not use or need. There will be no app-like folder structures and no odd syntax nobody else uses. For a reader deciding whether to use it, the practical translation is that you will not find a build-your-own-component-system here, and you will not find a dependency you did not ask for.

The naming history explains one oddity. The theme was called Air until version 3.7.8 in March 2018, when it was renamed air-light because `air` was already taken in the official WordPress theme directory. If you are following an old tutorial that installs a theme called Air, that is the same project under its previous name.

The template files themselves are the traditional set, following the WordPress Template Hierarchy as closely as the project can: 404, comments, footer, front-page, functions, header, index, page, search, sidebar, single and style.css, plus an `inc` directory, a `template-parts` directory and a `theme.json`. The presence of `theme.json` alongside classic PHP templates is the interesting tension in that list, and it is what lets the block editor be configured without turning the theme into a block theme.

The size numbers, and what they actually measure

The README publishes three measurements, and they are the reason the project leads with minimalism as more than a philosophy.

CSS gzipped is listed as 16.8 KB, down from 124.4 KB originally. JavaScript gzipped is 8.6 KB, from 28.6 KB. Front page HTML is 7.4 KB, from 29.4 KB. The compression ratios are the interesting part rather than the final numbers, because a ratio that large is what happens when a toolchain minifies and deduplicates assets that were written for development.

Two cautions are warranted. The figures carry no date and no measurement method, so they are a snapshot of one build at one moment, and a theme that adds a dependency will move them without anyone noticing. And the repository description advertises the theme as under 20 kB, which is not the same measurement as the sum of the README's own figures, since 16.8 KB of CSS and 8.6 KB of JS together exceed 20 kB before the HTML is counted. Both numbers are plausible for different things being measured, and the README does not say which.

The 7.4 KB of gzipped front page HTML is the figure worth pausing on. That is not a small document, and for a theme whose stated goal is minimalism it is the largest single asset in the list. Part of it is WordPress itself, since a default page includes the admin bar, the emoji script and a block editor bundle whether a theme wants them or not, and a theme cannot remove all of that without breaking compatibility. That constraint is worth understanding before concluding that a particular kilobyte count is the theme's fault.

The description's framing is worth repeating in the project's own terms: the theme is designed to be dependency-free, and it prefers the original WordPress way of doing things with no templating languages or frameworks. Whatever appears in the build tooling is a development dependency. Nothing in the list of assets has to be present at runtime because of the theme's own choices.

The textdomain rule, and why WordPress will overwrite your work

There is one piece of advice in this README that matters more than everything else, and it is easy to skim past because it is in a paragraph about the WordPress directory rather than in a warning.

air-light version 4.2.2 was approved to the official WordPress theme directory on June 4, 2018, and is marked accessibility-ready. But the README notes that all changes you make to the theme without generating your own or changing the textdomain will be overridden in theme updates, and instructs you to follow the instructions and replace the textdomain with your own if you use it as a starting point.

This is standard WordPress behaviour and it catches almost everyone once. WordPress identifies a theme update by the slug. As long as your copy carries the `air-light` slug, the update mechanism sees a theme it knows about and replaces the files. Your edits go. This is the same mechanism that protects users from a compromised theme, and starter themes built on a directory-listed parent are especially exposed to it because the parent keeps getting updated.

The fix is the textdomain, and the README tells you to change it. Once the textdomain is yours, WordPress no longer recognises the install as the directory theme, so the automatic update path stops applying. That is why the project also describes itself as a development theme with no updates inside WordPress by design: the version you get from the directory is a stable reference point, and the version you develop against is the one in the repository.

There is a second reason to change the textdomain that has nothing to do with updates. If you publish a site running an unmodified fork, the strings in it belong to the theme's textdomain, which means another site running the same theme can serve your translation files, and any string you change locally is a string WordPress will not let you translate through the normal route. Changing the textdomain makes the translations yours.

Practically: fork or copy the theme, change the textdomain in the first commit, and only then start editing templates. Ten minutes now avoids discovering the problem after your first update.

Parcel, PostCSS, cssnano and Sass: the build behind those numbers

The asset pipeline is the part of this repository that is not a WordPress convention, and reading the manifest tells you what it is.

Parcel is the bundler, configured through `parcel.config.js` with two configuration files, `.parcelrc` for builds and `.parcelrc.watch` for the dev server. The Sass transformer comes from `@parcel/transformer-sass`, and `sass` itself is a direct dev dependency. PostCSS runs with `postcss-calc` and `postcss-scss` as plugins, and cssnano with its advanced preset does the minification, which is where the compression ratios in the README come from. SVGO with its own configuration handles image assets, and `caniuse-lite` plus a `.browserslistrc` decide what the browser targets are.

The scripts show the two modes clearly. A production build is a two-step parallel run of the styles build and the JavaScript build:

"build": "npm-run-all build:styles build:js",
"browsersync": "node parcel/browsersync.js",
"version": "10.2.0",
"name": "air-light"

The development script is the more interesting one. It runs four named processes concurrently, labelled CSS, JS, BLOCKS and SYNC: a CSS watcher, a Parcel watch over both `front-end.js` and `editor.js` with source maps, hot module replacement and caching all disabled, a separate blocks watcher, and the browser sync. Two consequences are visible in the flags. The front-end and the block editor are separate entry points, so the editor bundle never ships to a visitor who is only reading, which is a real saving on a page that includes both. And `--no-cache` in the watcher means a developer editing a Sass file that Parcel has already transformed gets a rebuild rather than a stale artefact.

The PHP side has its own toolchain, and it is separate. There is a `composer.json` and `composer.lock` for PHP dependencies, and a `phpcs.xml` for PHP_CodeSniffer, which is how the WordPress Theme Coding Standards are actually enforced rather than merely cited. Splitting the two means a front-end contributor never needs PHP tooling installed and a PHP contributor never needs npm.

One more piece of the toolchain is worth calling out, because it is a small thing that says a lot. The organisation publishes its own shared configuration as npm packages, `@digitoimistodude/code-quality-checks` and `@digitoimistodude/stylelint-config`, and consumes them here. The agency's rules travel with the agency's projects, and a contributor does not have to read a hundred lines of ESLint configuration to find out what is enforced.

Accessibility as something a build fails on

The theme is described as accessibility-ready in the WordPress directory, and the more interesting fact is what backs that up in the repository.

Accessibility is linted. The dev dependencies include `hint-axe`, which is webhint's accessibility rule set, and `eslint-plugin-jsx-a11y` for JavaScript and JSX accessibility rules, and there is an `.accessibilityrc` configuration file at the top level. Alongside them sit a `.hintrc` for the rest of webhint's rules, `.eslintrc.js` with an import resolver, `.stylelintrc` and `.stylelintignore` for CSS, `.prettierrc` and `.prettierignore` for formatting, `.svgo.yml` for images, `.editorconfig` for whitespace, and a `.nvmrc` pinning the Node version so the build is reproducible across machines.

The linting surface is broad, and two of the webhint plugins are worth naming because they are the ones that catch real regressions rather than style. `hint-button-type` catches buttons without an explicit type, which breaks forms in ways that are invisible until a user's data goes somewhere unexpected. `hint-compat-api` flags browser API usage that is not in your browserslist targets, which is the failure mode that makes a site work on the developer's machine and break on a client's.

The continuous integration is where all of this becomes real. The README carries five separate build status badges rather than one: PHP 8.3, PHP, HTML, JavaScript and CSS. Five workflows means a change that breaks only the CSS pipeline fails only the CSS workflow, so a contributor gets a signal about the thing they touched. For a theme whose main claim is that it is small and accessible, having a build fail on an accessibility violation is the difference between a claim and a guarantee.

The remaining structural point is that there is no framework. React appears in the dev dependencies only for the block editor's JavaScript, and the templates are plain PHP files that WordPress includes. The theme's own mission statement rules out templating languages and app-like folder structures, and the dependency list is consistent with that claim rather than contradicting it.

A development theme, and two documentation files for two audiences

The README is unambiguous about what Air is not, and this is the section to read before you install it.

Air is described as a development theme, so it has updates very often, and by using it you agree that anything can change in a different direction without warning when you look at the development branch next time. It has no updates inside WordPress by design. It is not meant to be a theme for everyone, which the README explains as it not having the parts that multi-purpose themes include for non-technical people, with a pointer to its own section on disabled features.

And then the recommendation that settles the question for a lot of readers: if you need something more extended, the README suggests Sage. That is the project naming the alternative it considers better suited, which is a mark of honesty rather than of weakness.

The two-document structure is worth noticing. There is a `README.md` for developers and a `readme.txt` at the top level, which is the WordPress.org format required for a directory listing. Two audiences, two files, and the difference is why the directory approval in 2018 is a historical fact rather than a live channel. The directory copy and the repository have diverged, and the repository is where the work happens.

The version numbers explain themselves once you know that. The releases are 10.1.0 in February 2026, 10.1.1 in April, and 10.2.0 in June, which is a two-monthly cadence on a scheme of the project's own rather than anything WordPress requires. A `CHANGELOG.md` is present for the history, and the README's own table of contents includes a section on releasing a new version marked as staff only, so the release process is documented as a maintainer procedure rather than left to whoever needs it.

There is also a `CLAUDE.md` at the top level, which tells you the project has been set up for work with a coding agent in the loop. Combined with a `.github` directory carrying the issue templates and the five workflows, the repository's own tooling is more thorough than the theme it ships, which is not a criticism: a starter theme that expects you to build on it should have a build process worth copying.

air-light against Sage, and against forking _s yourself

Two comparisons, and the project names both of them before you do.

The first is Sage, from Roots, which the README recommends if you need something more extended. The difference is philosophical and it shows up immediately in the dependency list. Sage ships a modern build stack with a bundler configured for you, a view layer, and conventions for asset management, and it asks you to learn them. air-light ships the same category of tools but configures them its own way and leaves the template files as WordPress wrote them. Sage gives you more structure; air-light gives you less, and the cost of less is that you assemble the parts yourself.

If your project has more than one developer, or if you want the asset pipeline to be a solved problem rather than a decision, Sage is the better starting point. If you are one front-end developer who already knows Parcel and wants WordPress templates that look like WordPress templates, air-light is closer to what you would have written anyway.

The second comparison is more interesting, because air-light's own policy invites it. Since most changes in `_s` are implemented as soon as they are committed upstream, and since the theme's stated goal is to stay close to traditional WordPress, the zero-fork option is to start from `_s` and build your own pipeline. You would get the same upstream tracking, the same template hierarchy, the same coding standards, and none of the agency's opinions about which linters to run or how Parcel should be configured.

What you would lose is the part that is genuinely good: a working configuration of webhint with accessibility rules, an ESLint setup with the React and JSX accessibility plugins, Stylelint against the agency's shared config, PostCSS with cssnano for the compression that makes the size numbers work, and five separate CI workflows that fail a pull request when any one of those linters objects. Setting that up from scratch is a day of work at minimum, and most projects skip it.

So the honest summary is that air-light is `_s` plus a solved build and quality pipeline, at the cost of a textdomain and a rename you must do yourself. For the audience it names, that is a good trade.

MIT with two added clauses, and a licence file worth reading

The licence needs a careful reading, because the metadata and the README do not describe the same thing.

The repository is recorded as MIT, and the README says Air is licensed with the MIT License, which it explains as meaning you can use the theme commercially or privately, modify it, or distribute it. That much is standard. The README then adds two conditions that are not part of the MIT text: you are forbidden to hold the agency liable for anything, and you are forbidden to claim that what you do with the theme is made by them.

A liability waiver is common in themes and is broadly compatible with the intent of MIT, which already disclaims warranty. A prohibition on claiming the work as the agency's is a restriction on use that MIT does not contain, and it is a condition rather than a disclaimer. MIT as written grants the rights and disclaims the warranties; it does not add conditions. So the practical position is a permissive, MIT-shaped licence with one added restriction, and the file named `LICENSE.md` at the repository root is the authoritative text.

This is a description of what the files say rather than legal advice. For a commercial project the question is simple and worth answering before you ship: whether you need to rename the theme and remove the original attribution, and the README's own instruction to replace the textdomain with your own points the same way.

The maintenance picture is the healthiest of the projects in this series. Three releases in six months, a `CHANGELOG.md`, five continuous integration workflows, a large contributor list that the README links to, and an explicit invitation to send a first pull request. The last push was on 2026-09-19 and the repository is not archived.

What to take from all of this is fairly simple. Air-light is a well-maintained, well-tooled, deliberately incomplete starting point whose two real gotchas are both stated plainly in its own README: replace the textdomain or lose your changes to an update, and do not expect it to be a finished theme.

Editorial conclusion

Use air-light if you are a front-end developer who wants a thin WordPress starting point with a modern asset pipeline and WordPress coding standards already applied, and who will fork it rather than install it. Do not install it from the WordPress directory and edit it, because the README states that changes without your own textdomain are overwritten on update, and do not expect a finished site, because the project says so itself and points to Sage instead. Verify first by replacing the textdomain before your first commit, running npm run build to produce the assets, and checking the linters, since webhint with axe rules and eslint-plugin-jsx-a11y will fail your markup before a browser does.

Frequently asked questions

Official sources

1. digitoimistodude/air-light on GitHub
2. License: MIT
3. Project website
4. README
5. Releases