Vortex 1.37, released as Resonance, is a housekeeping release, and housekeeping releases are usually the ones that quietly make a project easier to live with. Demo code became removable in a single step, linting stopped queueing behind the build, the deployment tool started verifying itself, and CI stopped doing the same work twice. There are no breaking changes.
Demo code lives in its own module now
Every project template has the same awkward moment. You start from it, and it arrives with example code showing how the pieces fit together. That example code is genuinely useful on day one and slightly embarrassing 6 months later, when it is still sitting in your production codebase because nobody was certain what would break if they deleted it.
The demo code has moved out of ys_base into a new ys_demo module: the counter block with its CSS and JavaScript, the deploy hooks, and the example tests across unit, kernel, functional and functional JavaScript types.
Removing the demo content is now a single decision: switch the module off. The examples stay available for anyone learning the structure, and a production project stops carrying them. The installer also gained a prompt for choosing which custom modules to include, so a new project can start without the demo module at all.
Linting runs beside the build
Code style feedback is only useful if it arrives quickly. When linting is a step inside the main build, a missing space in a Twig template takes as long to report as a full site install, because it waits its turn behind everything else.
All the linting tools now run in a dedicated lint job in parallel with build: PHPCS, PHPStan, PHPMD, Rector, Twig CS Fixer, ESLint, Stylelint and Gherkin Lint. Style problems surface while the build is still running, so a developer can fix and push again without waiting for the whole pipeline.
The CircleCI configuration was split up at the same time, into separate files for project builds, Vortex integration tests, and dependency updates. Each concern can now be read and changed on its own.
The deployment tool verifies itself before it runs
Deployment tooling is a high-value target. It runs with credentials, it runs on every release, and it usually runs without anybody watching closely.
git-artifact, the tool Vortex uses to build and push deployment artefacts, now downloads as a binary from GitHub Releases and is checked against a SHA256 checksum before it runs. Every deployment verifies the tool against a known value, and the Composer dependency comes out of the deploy path entirely.
CI stops doing the same work twice
Several fixes here together take noise out of every pull request.
- Pushes to
feature/*andbugfix/*branches no longer trigger a build on their own. Those branches build through their pull request, which is where the result gets read. - Coverage comments replace the previous comment on a pull request. A long-running PR carries the current number, in place of a column of stale ones.
- S3 uploads fail loudly. An upload returning a non-2xx response used to be ignored silently, which is the worst way for a backup step to behave.
- Docker permission warnings in GitHub Actions were fixed, along with a coverage threshold check that lost its results when coverage was very low.
ahoy confirm also gained colour. Destructive commands prompt in red with a dimmed [y/N], so the prompt registers before you press enter out of habit.
Upgrading
There are no breaking changes. Most of this applies the moment you update: the lint job, the CircleCI split, the branch filtering, the verified deployment binary.
The one thing worth a decision is the demo module. If your project has outgrown the example code, disable ys_demo and it is gone, tests included.
Full details are in the GitHub release notes(Opens in a new tab/window), and the Vortex documentation(Opens in a new tab/window) covers the CI layout.
Related posts
