Swiss Knife Laravel Package

Technical Evaluation

Architecture fit: The package remains a framework-agnostic CLI toolset consumed as a dev dependency, so it sits alongside Laravel rather than inside it. Core checks (merge conflict detection, commented code, PSR-4 validation, search-regex) map cleanly onto Laravel's directory conventions. Symfony-only generators (generate-symfony-config-builders, split-config-per-package) stay excluded.

Release 2.7.0 improves fit in three ways:

• PHP 7.4–8.5 support spans the runtime floor/ceiling of every Laravel version we currently run (Laravel 8 through 12), so one toolchain version can serve a mixed-version repo estate.
• measure and features (ported from tomasvotruba/lines) add class/method-level LoC, complexity, and language-feature usage reporting. This is directly actionable for us: features output is an upgrade-readiness signal (which PHP features are in use before a version bump), and measure output feeds tech-debt reporting on app/ code.
• rector/jack commands under swiss-knife give us automated PHP version upgrade/downgrade transforms — relevant whenever a Laravel upgrade forces a PHP floor bump. Documented in README (#155), which lowers adoption cost.

Integration feasibility: Low. Dev-only Composer dependency invoked via vendor/bin, no runtime or container coupling, no service dependency. The only real work is CI wiring and command-name hygiene.

Technical risk: The removals are the material risk. spot-lazy-traits and the MockWire util are gone, plus an unspecified set of "low-value commands" (#142). Any Composer script, Makefile target, or CI job referencing those will fail hard rather than degrade. Mitigation exists — spot-lazy-traits is replaced by a PHPStan rule — but only if PHPStan is already a pipeline gate. PHP 8.5 support is forward-looking; treat it as "supported by the tool," not "validated by us."

Key questions:

1. Which exact commands were dropped in #142? We need an inventory before upgrading, not after a red pipeline.
2. Do any of our repos call spot-lazy-traits, MockWire, or the dropped commands from composer.json scripts or CI?
3. Is PHPStan already gating the repos that relied on spot-lazy-traits? If not, that check silently disappears.
4. Do we want measure/features in CI artifacts, a dashboard, or ad hoc only? Metric collection without an owner becomes noise.
5. Does jack's transform set cover the PHP version jumps in our next Laravel upgrade wave?
6. Do we want to test on PHP 8.5 before it is GA, or pin to 8.4 and wait?

Integration Approach

Stack fit: composer require --dev, invoked from CI and pre-commit hooks. Coexists with Pint, PHPStan, and PHPUnit without conflict; the PHPStan rule replacing spot-lazy-traits consolidates rather than adds a tool if PHPStan is already present. measure/features should be treated as report generators (write to artifact/JSON), not pass/fail gates, at least initially.

Migration path:

1. Grep the estate for dropped command names in composer.json scripts, Makefiles, and CI YAML.
2. Establish PHPStan rule parity for spot-lazy-traits before removing the old invocation.
3. Remove MockWire references; confirm no local tooling depends on it.
4. Bump to 2.7.0 in a single PR per repo, lockfile-pinned.
5. Adopt measure/features opportunistically on one pilot repo before wider rollout.

Compatibility: The 7.4–8.5 range covers all supported Laravel branches, but validate at both ends of our matrix — lowest PHP for the oldest Laravel, highest for the newest. The PHPStan rule and jack both have their own upstream version constraints; align those explicitly rather than letting Composer resolve independently.

Sequencing: Inventory → PHPStan parity → upgrade → pilot metrics → evaluate jack ahead of the next Laravel/PHP upgrade cycle. jack is the highest-leverage item but also the highest-blast-radius; it belongs after the upgrade is stable, scoped to a branch, not folded into the same change.

Operational Impact

Maintenance: Net reduction in surface area — upstream is consolidating commands and pushing trait detection into a rule we likely already run. Offset by one new version-alignment obligation (the PHPStan rule). Low ongoing cost.

Support: Upstream is effectively single-maintainer (Symplify / Tomas Votruba). Bus factor is the standing concern; mitigations are version pinning, avoiding dependence on freshly added commands in critical gates, and not building bespoke automation on jack until it has a release or two of field use.

Scaling: Per-repo, per-CI-job CLI execution. measure/features over large Laravel monorepos will be the slow path — scope to app//src/, and run on a schedule or on demand rather than on every commit. Other checks are fast and scale fine.

Failure modes:

• CI hard-fails on a removed command after upgrade (most likely failure; detectable pre-merge by inventory).
• PHPStan rule misconfigured → false positives blocking merges, or false negatives silently dropping coverage.
• Metrics collected but never reviewed — cost with no benefit; assign an owner or skip.
• jack producing large, hard-to-review diffs; run on a branch with the test suite as the gate.
• Rollback is trivial across all of these: revert the version pin.

Ramp-up: Low. Hours to inventory and upgrade, roughly half a day to wire the PHPStan rule and confirm parity, and about a sprint to establish measure/features baselines and decide whether they earn a place in reporting. No application-team training needed — the output is CI artifacts and existing-style lint messages.