Once a stylesheet passes a few hundred lines you want variables, nesting and separate files. Wiring up SCSS is the easy part. The real decision comes straight after: do you commit the compiled CSS?
The simplest possible setup
All you need is a compiler and two scripts. Source lives in assets/scss/, output in assets/dist/, and the enqueue points at the output only.
{
"scripts": {
"build": "sass assets/scss/main.scss assets/dist/main.css --style=compressed --no-source-map",
"watch": "sass --watch assets/scss/main.scss:assets/dist/main.css"
}
}Keep a single entry point that pulls in everything else and you can split the source as finely as you like while the browser still makes one request. That is why SCSS partials cost nothing at runtime.
Node is only needed at build time
This is the crux of the decision. The compiler only has to run on a developer’s machine; the production host needs no Node at all. It is better off without it — smaller attack surface, smaller image, simpler deploys.
But WordPress themes are typically deployed by copying files. Whether you ship a zip or place the repository directly, there is no build stage in the middle. If the compiled file is not in the repository, the styles simply do not exist on the server.
State the cost honestly
Committing build artefacts is discouraged in ordinary application code, and the reasons for that convention apply here too. They do not vanish because this is a theme.
The short version: if you already have a deployment pipeline that can run a build, keep the output out of the repository. In a conventional WordPress setup where deployment means uploading files, committing is the right call. Whichever way you go, write down why — so the next person does not restage the entire argument from scratch.
If you do commit, manage the cost. Make it a rule that dist/ is never hand-edited, run the build before committing, and resolve merge conflicts by rebuilding rather than merging. Hand-merging compiled output is meaningless by definition.
A failed build empties the file
One trap is worth knowing. Compilers generally truncate the output file before writing it, so a syntax error leaves you with an empty artefact. The page renders with no styling at all, and the cause is not in the CSS — it is in the terminal you stopped reading.
So make confirming a successful build part of committing, and note that having the artefact under version control is exactly the safety net here. Having somewhere to roll back to is one more point in the committing column.
Source maps are a separate call. They are useful in development, but shipping them publishes your SCSS structure. That is not dangerous information, yet publishing it deliberately and publishing it unknowingly are different things.
Articles on repository practice and deployment live in the Development workflow archive, and if you would rather hand over the whole environment including the pipeline, it is covered by our optimization program.
Next part
Once you start drawing screens you start printing values. The next part is escaping on output — why it belongs at output rather than input, and why the function changes with the context.