Php File Manipulator Laravel Package

Technical Evaluation

Architecture fit: Archetype is best treated as a development/static-analysis dependency for Laravel codebase introspection, not a runtime library. It fits Laravel 10–13 on PHP 8.1–8.4 via php-parser ^5.0, and is useful where a TPM wants repeatable visibility into Laravel structures such as models, controllers, service providers, and AST-level code patterns. Its largest known consumer is Statamic, which is a positive ecosystem signal but also means compatibility evidence is strongest along Statamic’s exercised paths.

Integration feasibility: v2.0.1 is maintenance-only and declares no API changes. It is drop-in from 2.0.0 on PHP 8.1+, and 1.x users can upgrade without changing their own code, though Composer resolution may require dependency updates because 1.x pins nikic/php-parser ^4.11. The new php requirement (^8.1) is a packaging improvement and makes platform expectations explicit.

Technical risk: The main forward-looking risk is PHP 9: the package deliberately caps PHP compatibility because its AST node-identity mechanism relies on dynamic properties. Composer will fail fast instead of installing a package that fatals, but this creates a future migration obligation. Legacy 1.x remains a constraint for older Laravel/PHP stacks and conflicts with anything requiring php-parser 5, including Pest 3 and newer. The release materially reduces current risk by adding verified CI coverage, fixing ->throw() matching, broadening getReflection() error handling from Exception to Throwable, resolving PHP 8.4 implicit-nullable deprecations, and correcting shipped config paths.

Key questions: Are target applications on PHP 8.1–8.4 and Laravel 10–13? Is any consumer pinned to Statamic 4/3.4, which keeps it on 1.x? Do we need Pest 3 or other php-parser 5 dependencies? Is PHP 9 on the roadmap within this package’s expected lifespan? Do our own analysis paths depend on ->throw(), getReflection(), or the corrected commands_root/controllers_root config? Has the package’s license been reviewed now that LICENSE.md exists?

Integration Approach

Stack fit: Use 2.x for Laravel 10, 11, 12, or 13 with PHP 8.1–8.4 and php-parser 5. Keep 1.x only for PHP 7.4–8.1 and Laravel 6–9, accepting its php-parser 4.11 constraint. For Statamic-based products, 2.0.1 fits Statamic 5 on Laravel 12 and Statamic 6 on Laravel 13; Statamic 4 and 3.4 remain on ^1.0.3 and are unaffected.

Migration path: From 2.0.0, upgrade directly on PHP 8.1+. From 1.x, treat the upgrade as a dependency-resolution task rather than an application-code task: update Composer constraints, resolve php-parser 5 conflicts, run the application test suite, and re-run any Archetype-based introspection jobs. If Composer refuses to resolve ajthinking/archetype, the likely cause is the 1.x php-parser pin. No application code changes are required per the release notes.

Compatibility: The release provides much stronger evidence than 2.0.0: twelve PHP × Laravel combinations in CI, plus macOS and PHPStan. Statamic 5 and 6 real installs resolve 2.0.1 and produce byte-identical output to 2.0.0 across every code path Statamic exercises. That is good evidence for Statamic consumers, but it is not proof for every custom Archetype query; our own test suite and representative queries should still be run.

Sequencing: First inventory PHP, Laravel, Statamic, Pest, and php-parser constraints. Then pilot 2.0.1 in a non-production branch, run Composer resolution, execute the full test suite, and compare outputs from any model/controller/service-provider discovery jobs. Review published config if we override commands_root or controllers_root. Roll out to CI/static-analysis tooling after parity is confirmed. Defer PHP 9 planning until the package resolves its dynamic-property dependency.

Operational Impact

Maintenance: v2.0.1 is a low-churn maintenance release with meaningful hygiene improvements: changelog, LICENSE.md, Dependabot config, explicit PHP requirement, and a real CI matrix. That reduces the “works but no evidence” risk that existed after 2.0.0. Ongoing maintenance risk is mainly dependency-driven: future php-parser 5 releases and the eventual PHP 9 incompatibility.

Support: Support complexity is low when the application matches the supported matrix. The main support burden will come from legacy 1.x users on PHP 7.4/8.0 or Laravel 6–9, and from Composer conflicts where another dependency needs php-parser 5. Statamic 4/3.4 consumers should not be pushed to 2.x unless they also upgrade their Statamic and Laravel baselines.

Scaling: The package is suited to CI, developer tooling, and batch code-analysis jobs rather than request-path workloads. The getReflection() fix improves robustness on larger or legacy codebases because a single file with an unautoloadable parent class or trait now raises a Throwable that is caught and skipped rather than killing the whole query. Very large repositories should still get a performance smoke test if Archetype scans run frequently in CI.

Failure modes: PHP 9 installs are blocked by Composer, which is safer than a fatal runtime failure but requires future planning. The ->throw() fix means prior 2.0.0 analysis may have silently missed throw expressions; any downstream reports relying on that path should be regenerated. Autoload failures are now skipped per file, which improves resilience but could mask missing autoload configuration unless teams monitor skipped files. The corrected config roots remove a shipped-config defect, but published/overridden configs should be checked.

Ramp-up: Ramp-up is low for Laravel/PHP teams because integration is Composer-based and the release is drop-in for 2.0.0. A TPM should document the supported PHP/Laravel matrix, require a short 1.x-to-2.x dependency spike where applicable, and set the expectation that 2.0.1 is an evidence-and-fixes release rather than a feature release.