Praspel Laravel Package

Technical Evaluation

Architecture fit: hoa/praspel is not a Laravel package. It is an archived Hoa-project PHP library centered on a specification/contract DSL, not a Laravel-native validation, authorization, or API-contract layer. It has no service provider, facade, config publishing, middleware, or Eloquent/HTTP integration. For a Laravel TPM, that means the architectural fit is poor unless the goal is a narrow, dev-only design-by-contract or specification-driven testing experiment.

Integration feasibility: Composer installation may be technically possible, but feasibility is low for modern Laravel. The last release was 2017-01-10, the repository is archived, and it has zero dependents. Laravel applications on PHP 8.x are likely to encounter PHP-version, autoloading, dependency, or API-compatibility issues. Any integration should be treated as a sandbox spike, not a production dependency.

Technical risk: High. The package is abandoned, unmaintained, and has no upstream security or compatibility patches. Its Hoa conventions and DSL add a nonstandard learning curve. The main risk is not just breakage; it is false confidence from adopting an unmaintained contract tool that does not integrate with Laravel’s native testing, validation, or static-analysis ecosystem.

Key questions:

• Is the actual need runtime contract enforcement, test generation, API contract testing, or internal specification documentation?
• Does hoa/praspel install and run on the target PHP/Laravel version under Composer 2?
• Are its transitive Hoa dependencies maintained, compatible, and free of known vulnerabilities?
• Can the same outcome be achieved with PHPUnit/Pest, Laravel validation, Psalm/PHPStan, OpenAPI, or Pact?
• Is the TPM prepared to fork and own the library if a proof of concept succeeds?
• What is the exit criterion for a time-boxed spike, and who approves any production exception?

TPM recommendation: No-go for production. Allow only a time-boxed, isolated spike to evaluate the specification/contract concept. Do not add it to Laravel runtime dependencies.

Integration Approach

Stack fit: Poor as a framework component. It does not map cleanly to Laravel’s HTTP kernel, service container, validation pipeline, or test harness. If used at all, it belongs in a separate tools/ or dev-only Composer context, never in application runtime code.

Migration path: There is no meaningful “migrate into Laravel” path because there is no Laravel integration to migrate. The practical path is to extract the useful concept — explicit preconditions, postconditions, invariants, or specification-driven tests — and implement it with native Laravel/PHP tooling. If a spike proves Praspel valuable, wrap it behind an internal dev script and document a replacement path before adoption.

Compatibility: Verify PHP constraint compatibility, Composer 2 behavior, autoloading, and conflicts with Laravel’s dependency graph. Expect Hoa-specific conventions and legacy assumptions. Pin the exact PHP version and dependency set in a disposable container. Do not rely on semantic-version guarantees.

Sequencing:

1. Define the use case and success metric: contract testing, spec documentation, or test generation.
2. Run a one-to-two-day sandbox spike in Docker with the target PHP version.
3. Compare results against PHPUnit/Pest, Laravel validation, Psalm/PHPStan, OpenAPI, or Pact.
4. Record compatibility, maintenance, and security findings.
5. Decide: reject, use as reference only, or contain as a dev-only internal tool.
6. If contained, assign an owner, fork policy, and removal date.

Operational Impact

Maintenance: Effectively zero upstream maintenance. The TPM must assume full ownership of any fork, including PHP upgrades, dependency patches, and security review. That is rarely justified for a 41-star, archived package with zero dependents.

Support: No vendor support, no active community, and no Laravel-specific documentation. Internal developers will rely on source reading and Hoa-era examples. Escalation paths are limited to the TPM’s own team.

Scaling: As a dev/test tool, scaling concerns are mostly CI time, parser overhead, and developer onboarding. As a runtime component, it would add avoidable latency, memory, and operational surface area. Keep it out of request paths.

Failure modes: Modern PHP incompatibility, Composer resolution failures, abandoned transitive dependencies, missing security patches, DSL misuse, false confidence in contract coverage, and developer confusion when native Laravel tests already cover the behavior.

Ramp-up: Medium-to-high. The Praspel DSL and Hoa conventions are unfamiliar, documentation is sparse, and there are no Laravel examples. A spike should be time-boxed and paired with a native-tool comparison so the team does not over-invest in an unmaintained dependency.