Phpspec Typehintedmethods Laravel Package

Product Decisions This Supports

• Dev-experience / tooling standardization: Decides whether phpspec-generated skeletons match our typed code standards out of the box, eliminating a manual cleanup step every time a spec is generated.
• Build vs. buy for a codegen nicety: The capability is roughly one phpspec extension class. Buying (composer --dev) is cheaper than building only if the package still works on our PHP version; otherwise a PHP-CS-Fixer/Rector post-step or a ~100-line in-house extension is the cheaper path.
• Test-framework direction: This only has value inside a phpspec-centric workflow. Choosing this package is downstream of the real decision — phpspec vs. PHPUnit/Pest — and it should be scoped as a rider on that decision, not a decision of its own.
• Standards enforcement in generated code: Type-hinted generated methods keep static analysis (PHPStan/Psalm) effective on stubs and mocks, closing the "generated code is exempt from our typing rules" gap.
• Representative use cases: Greenfield domain-layer design-by-spec; retrofitting parameter/return types into legacy specs; teams whose DI containers, mocks, or static analyzers benefit from explicit generated signatures.
• Roadmap placement: Treat this as engineering hygiene, not a product differentiator. It belongs in a tooling/infra maintenance line item, not a feature roadmap narrative.

When to Consider This Package

• You already use phpspec and intend to keep using it. If phpspec isn't in the stack, stop here — Laravel's idiomatic path is PHPUnit/Pest, and this package adds nothing there.
• You are willing to own it. Last release 2018-07-15, 30 stars, 0 dependents means effectively unmaintained. Adopt only if you can vendor or fork it and patch it yourself.
• PHP version compatibility is verified first. A 2018-era extension predates union types, intersection types, static, never, enums, and readonly — validate behavior on PHP 8.x before committing.
• Risk tolerance is high and blast radius is low. It's a dev-only, MIT-licensed dependency with zero runtime footprint, so the downside is bounded to developer friction, not production.
• Look elsewhere when: you're on the Laravel-default testing stack; you need PHP 8+ type fidelity in generated code; or generated code is a small enough share of output that adding type hints via PHP-CS-Fixer/Rector rules is simpler and better maintained.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed developer-experience add-on that keeps phpspec-generated test stubs consistent with our typed-code standards, so engineers spend less time hand-editing boilerplate. Cost is near zero — a dev-only dependency with no runtime or infrastructure footprint. The material caveat is maintenance: last release was 2018 with a very small user base, so treat it as a "vendor-if-needed" utility rather than a platform commitment. It is only relevant if we're already standardized on phpspec.

To engineering: One extension class that teaches phpspec's code generator to emit parameter and return type hints derived from the spec. Adoption is composer require --dev plus registration in phpspec.yml. Before merging, confirm PHP 8.x compatibility and assume we may need to carry patches. If we're not on phpspec, skip it entirely and handle type-hint cleanup with PHP-CS-Fixer/Rector in a PHPUnit or Pest workflow.