Symfony Console Laravel Package

Product Decisions This Supports

• Upgrade scheduling for the config-generation layer (v4.7.x → v4.8.0). This release changes the bytes written for inputs that were previously accepted but produced broken or unsafe files. Treat it as a planned change-management event: upgrade, regenerate every managed artifact once, and expect --check to flag the previously broken files exactly once. Do not let it land silently inside an unrelated deploy.
• Security posture of deployment tooling. The systemd fix closes a real injection path: a newline in working_directory (or any directive value) terminated the directive and started a new one, so a value such as "/srv\nExecStartPre=/bin/rm -rf /" produced a unit that systemd-analyze verify happily accepted with both directives present. If any value reaching these templates is tenant-supplied, operator-supplied, or imported from an external source (repo, database, onboarding form), this release is a prerequisite, not a nice-to-have — and it should be referenced in the security review and audit evidence for the deployment pipeline.
• Whether to expose self-service config values to customers/internal teams. The escaping fixes for $ (systemd variable expansion — a --secret=pa$word argument silently became pa$word with $word substituted), standalone ; in ExecStart, cron % (which truncated the command and pushed the remainder to stdin), and Supervisor %-interpolation make it defensible to accept externally influenced values for secrets, log paths, and command arguments. Until this release, that was not a decision we could make.
• Build vs buy for ops-config generation. .example/ is a runnable, CI-gated slice of a realistic product-catalogue operation covering every public capability (custom commands, instance/memory/time-limit traits, environment-driven template selection, generated crontab rows, Supervisor programs, systemd units, Kubernetes values, all three preview modes, installed from the working tree via a path repository). That materially lowers the cost of a spike: we can fork the example as our own ops repo skeleton instead of writing a bespoke generator or reaching for Ansible.
• CI drift detection as a product-level guardrail. --diff and --check are only trustworthy if they explain why a file differs. This release makes CRLF-vs-LF show up as \ line endings differ under the ---/+++ header instead of a bare [changed] with nothing beneath it, and it stops --diff from showing empty hunks for files no command declares (now correctly rendered against +++ /dev/null). That turns --check into a viable merge gate rather than a noisy one teams learn to ignore.
• Adopting systemd-analyze verify (and friends) as our own pre-merge validation. The example suite runs generated units through systemd-analyze verify wherever it is on PATH, and asserts crontab/Supervisor/K8s output "the way a deployment pipeline reads them." That is a validation pattern worth copying into our pipeline regardless of the vendor decision.
• Roadmap input: multi-target support. One bundle configuration driving systemd (VMs), cron (legacy hosts), Supervisor (containers), and Kubernetes values is the differentiator. If our roadmap moves toward a single orchestrator, the value of the package narrows — worth flagging now rather than after deeper integration.
• Safe-delete behaviour for managed directories. save() no longer removes a directory reachable through a symlink (dangling symlinks are still reported as removed). This is the kind of data-loss-adjacent behaviour that needs an explicit decision recorded before we let the tool prune production paths.

When to Consider This Package

Consider it when most of the following hold:

• You generate systemd units, crontabs, Supervisor programs, or Kubernetes values files for more than one application, environment, or target type, and today that is done with hand-edited files, copy-paste, or ad-hoc shell/CI templating.
• You want the config to be derived from code and a bundle configuration so environments select templates, rather than environments being manually maintained.
• You need preview and drift detection (--diff, --check, plus the other preview modes) wired into CI, with output a reviewer can actually read.
• Some values — working directories, log paths, secrets passed as command arguments, command parts — originate outside the immediate team and must be escaped correctly per target format.
• You already run Laravel/PHP in the delivery path, or you are willing to run a PHP CLI step in CI for config generation.
• You want the generated artifacts validated by the target's own tooling in tests (the .example/ slice and its example CI job show this is supported and maintained).

Look elsewhere when:

• You are Kubernetes-only. Helm/Kustomize/Argo covers this with far more ecosystem support; the multi-target breadth here is wasted.
• You need runtime orchestration (restarts, health reconciliation, rolling deploys) rather than file generation — this package writes files; it does not supervise processes.
• You need Windows services, OpenRC, runit, or other init systems outside the four targets covered.
• You want fleet-wide configuration management (Ansible, Puppet, Chef, Salt) with inventory, idempotent remote execution, and secrets management. This generates artifacts; it does not push them.
• Your footprint is a single app on a single host. A checked-in template plus systemctl daemon-reload is cheaper to own than a new dependency, however well tested.
• You cannot absorb a one-time regeneration of all managed files, or you have no way to diff generated output against what is currently deployed before applying it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We generate the deployment configuration that tells the operating system, the scheduler, the process supervisor, and Kubernetes how to run our services. Today that is largely hand-maintained, which means drift between environments and no reliable way to prove what changed. This package makes those files generated artifacts: one configuration in, deterministic files out, with a diff and a check mode we can run in CI so a bad change is caught before it ships. The v4.8.0 release is a hardening release — it closes a class of bug where a newline or a $ or a % inside a configuration value could silently change the meaning of the generated file, including injecting an extra privileged command into a systemd unit. The upgrade is low effort and the only operational cost is a single regeneration pass; the return is a deployment path we can audit, review, and gate.

For engineering leads: escaping is now correct per target rather than approximately correct — systemd gets $$ and a lone \;, cron gets \% with POSIX single-quoted log paths (fixing locale-dependent mangling of non-ASCII paths such as /srv/données), Supervisor gets %% and one-pass placeholder substitution so a literal %user% in a command is no longer rewritten. --check is safe to gate merges on: line-ending-only differences are explained, undeclared files diff against /dev/null, and save() refuses to delete through a symlink. The failure modes are explicit (InvalidConfigurationException at generation time) instead of producing a file that looks valid and isn't.

For the platform/ops team: adopt the .example/ slice as our starting layout — it is a working, CI-gated reference covering custom commands, the instance and memory/time-limit traits, environment-selected templates, and all three preview modes, installed from a path repository. Copy its validation habits: run generated units through systemd-analyze verify before merge, and assert crontab and Supervisor output as the deployment pipeline would read them. The directory is export-ignored, so it will never appear in our vendor/ tree.

Ask: approve the upgrade with a scheduled one-time regeneration of all managed artifacts, and approve a two-week spike that forks .example/ into our ops repo skeleton with --check wired into CI.