jonpurvis/squeaky
Squeaky is a Laravel package that scans your Blade templates and CSS to find unused classes, helping you trim dead styles and keep front-end assets lean. Simple to install and run, it makes cleaning up your app's CSS a quick, repeatable part of your workflow.
Architecture fit: The v3.3.0 release is a compatibility-boundary release, not a feature release. It adds PestPHP 5 support and drops Laravel 10 and 11 support. That makes architecture fit conditional: the package is a reasonable fit only if the application is already on the newly supported Laravel baseline, likely Laravel 12+, and the team’s test stack can move to PestPHP 5. If the application remains on Laravel 10 or 11, v3.3.0 is not a viable upgrade without a platform upgrade. If the package is used only in development/CI, runtime architecture impact is low; if it is used in production paths, treat the Laravel constraint change as a runtime compatibility risk until verified.
Integration feasibility: Feasible after confirming the exact Composer constraints in v3.3.0. The release note is too sparse for a TPM sign-off: it compares v2.4.0 to v3.3.0 but lists only one change, which suggests prior v3.x changes may be bundled and not described in this note. Integration is straightforward for a standard Laravel package, but only after the team verifies supported Laravel/PHP versions, PestPHP 5 compatibility, and whether the package is dev-only or runtime. Do not schedule adoption solely from this release note.
Technical risk: The main risk is the breaking support drop for Laravel 10 and 11. Secondary risks are incomplete release documentation, possible hidden breaking changes between v2.4.0 and v3.3.0, transitive dependency conflicts, and CI disruption from PestPHP 5. SemVer major-version treatment is appropriate, but the release note does not provide enough detail for impact analysis. A v2.4.0 fallback may be available for Laravel 10/11, but its maintenance and security posture need confirmation.
Key questions:
Stack fit: Confirm the application is on the Laravel version supported by v3.3.0 and that the team can run PestPHP 5. If the application is on Laravel 10 or 11, v3.3.0 does not fit without a Laravel upgrade. If the package is dev-only, isolate it to the test/CI dependency set first.
Migration path: Inventory current usage with composer why and composer show. Create a dedicated upgrade branch. If needed, upgrade Laravel first, then update the package, then align PestPHP to v5. Commit the lockfile and validate in CI before merging. For Laravel 10/11 applications, either stay on v2.4.0 or treat the package upgrade as part of a larger Laravel upgrade programme rather than a standalone package bump.
Compatibility: Check the package’s composer.json constraints, Laravel package discovery, published config, service providers, test helpers, and any Pest-specific integration. Verify the CI matrix covers the target PHP and Laravel versions. Confirm whether PestPHP 5 changes test APIs or plugins used by the team.
Sequencing: First, confirm the support matrix and read the full v2.4.0-to-v3.3.0 changelog. Second, decide whether the application is on a supported Laravel baseline. Third, upgrade Laravel/PHP if required. Fourth, update the package and PestPHP in a branch. Fifth, run the full test suite, static analysis, and a production-like smoke test if runtime usage exists. Sixth, document rollback to the prior package/Laravel combination. Do not combine this with unrelated framework upgrades unless the team has capacity for a single, well-tested platform change.
Maintenance: The v2 line becomes the practical path for Laravel 10/11 users, so the team needs an explicit position on staying on v2.4.0 versus upgrading the platform. Pin the package version and review the full changelog before future minor updates. The appearance of a new contributor is positive but does not remove the need to assess maintainer bandwidth and release discipline.
Support: Support is tightly coupled to Laravel and PestPHP release cadence. The team should assign an internal owner for this dependency and define a support window. If the package is runtime-critical, require a documented upgrade and rollback plan before adoption.
Scaling: If the package is dev/CI-only, scaling impact is limited to CI time and test reliability. If it runs in production, assess request-path overhead, failure isolation, and whether the package can be disabled or bypassed without redeploying the application.
Failure modes: Likely failure modes are Composer resolution failures after the Laravel constraint drop, CI failures from PestPHP 5 incompatibility, missed breaking changes from earlier v3.x releases, runtime incompatibility on unsupported Laravel versions, and false confidence from a passing test suite that does not cover the package’s integration points. Rollback complexity depends on whether the Laravel upgrade and package upgrade are coupled.
Ramp-up: Ramp-up is low for teams already on Laravel 12+ and familiar with Pest. It is moderate for teams moving from Laravel 10/11 or Pest 4 to Pest 5, because the package upgrade becomes a platform and test-tooling migration. Budget time for a compatibility spike, CI validation, and documentation of the supported baseline rather than treating v3.3.0 as a routine patch.
How can I help you explore Laravel packages today?