Summary
The tooling package ships vortex-update, a script whose only job is to download the Vortex CLI (the installer distributed from vortextemplate.com) and run it. Updating a project from the template isn't a project-tooling concern - it's the Vortex CLI's own job. Remove the script from drevops/vortex-tooling and have the ahoy update-vortex command use the Vortex CLI directly: run the locally available binary when present, download it when not.
Details
Current state:
ahoy update-vortex runs ./vendor/bin/vortex-update.vortex-update downloads the installer from https://www.vortextemplate.com/v1/install (unless VORTEX_INSTALLER_PATH points to a local copy) and runs it against the template repo, honoring VORTEX_INSTALLER_TEMPLATE_REPO and the --interactive flag.- The script runs on the host, outside containers, so it doesn't use any of the tooling package's project-operation context - it's an odd fit for the package.
Proposed change:
- Remove
vortex-update from the tooling package: the script, its bin entry in composer.json, and its unit tests.
- Rework the
ahoy update-vortex command to invoke the Vortex CLI directly: use the vortex binary if it's already available, otherwise download it first and run the downloaded copy.
- Keep the existing override points (template repo URI/ref, local installer path, interactive mode) working through the CLI invocation.
Why:
- The tooling package sheds a concern that was never really its own:
drevops/vortex-tooling is about operating a project (databases, deployments, notifications), not maintaining its template lineage.
- Updates always go through the Vortex CLI's native flow, so installer improvements reach consumers without a tooling release in between.
- One less shipped script to maintain and publish in the mirror.
Affected areas:
.vortex/tooling/src/vortex-update, the bin entry in .vortex/tooling/composer.json, and .vortex/tooling/tests/Unit/UpdateVortexTest.php.- The
update-vortex command in .ahoy.yml, plus regenerated installer fixtures.
- Docs:
updating-vortex.mdx and installation.mdx.
Summary
The tooling package ships
vortex-update, a script whose only job is to download the Vortex CLI (the installer distributed from vortextemplate.com) and run it. Updating a project from the template isn't a project-tooling concern - it's the Vortex CLI's own job. Remove the script fromdrevops/vortex-toolingand have theahoy update-vortexcommand use the Vortex CLI directly: run the locally available binary when present, download it when not.Details
Current state:
ahoy update-vortexruns./vendor/bin/vortex-update.vortex-updatedownloads the installer fromhttps://www.vortextemplate.com/v1/install(unlessVORTEX_INSTALLER_PATHpoints to a local copy) and runs it against the template repo, honoringVORTEX_INSTALLER_TEMPLATE_REPOand the--interactiveflag.Proposed change:
vortex-updatefrom the tooling package: the script, itsbinentry incomposer.json, and its unit tests.ahoy update-vortexcommand to invoke the Vortex CLI directly: use thevortexbinary if it's already available, otherwise download it first and run the downloaded copy.Why:
drevops/vortex-toolingis about operating a project (databases, deployments, notifications), not maintaining its template lineage.Affected areas:
.vortex/tooling/src/vortex-update, thebinentry in.vortex/tooling/composer.json, and.vortex/tooling/tests/Unit/UpdateVortexTest.php.update-vortexcommand in.ahoy.yml, plus regenerated installer fixtures.updating-vortex.mdxandinstallation.mdx.