Php Language Extensions Laravel Package

Product Decisions This Supports

• Where to draw architectural guardrails in code vs. documentation. This package turns conventions like "value objects are immutable," "this method has no side effects," and "instances are only created through named constructors" into attributes that PHPStan verifies on every CI run. The PM decision it informs is whether architecture rules live in a wiki that rots, or in the build that fails a pull request.
• Build vs. buy for internal static-analysis rules. Teams routinely write and maintain custom PHPStan/Rector rules for immutability, purity, and constructor discipline. Adopting this package is effectively a "buy" (MIT, free) decision that removes an estimated multi-week internal tooling effort and its ongoing maintenance.
• Domain modeling standards for DDD/CQRS-style codebases. #[Struct], #[Immutable], and #[ReadOnly] give a shared, checkable vocabulary for entities, value objects, and events. This supports a roadmap decision to standardize on immutable value objects rather than letting each squad invent its own conventions.
• Risk posture on public API and contract surfaces. #[Pure] and #[Throws]-style enforcement reduce the class of bugs where a "getter" quietly mutates state or an undocumented exception escapes a boundary — relevant when deciding how much to invest in contract safety versus runtime validation.
• Team scaling and onboarding. Every attribute is self-documenting at the call site and enforced mechanically, which lowers the review burden on senior engineers and shortens the ramp for new hires. This is a lever on the "how fast can we add engineers" decision, not a feature decision.
• Refactor and modernization sequencing. Because attributes are inert at runtime, they can be introduced file-by-file alongside a PHP 8.1+/native readonly migration, letting the team phase enforcement in rather than freezing feature work for a big-bang cleanup.
• Sequencing of dev-experience investment. This competes for the same budget as test coverage, CI speed, and linting. The decision is whether static-analysis depth is a higher-leverage investment than additional integration tests for the next quarter.

When to Consider This Package

Adopt when most of these hold:

• The codebase is PHP 8.1+ and already runs PHPStan (or is prepared to add it) in CI — this package is a static-analysis extension, not a runtime library, and delivers zero value without an analyzer in the pipeline.
• The product has a domain layer with real invariants — money, identifiers, date ranges, state machines, event payloads — where accidental mutation or hidden side effects cause expensive defects.
• You have more than a handful of engineers or a codebase large enough that "everyone knows the convention" has stopped being true.
• The team is comfortable with attributes and generics-free static analysis and accepts that a red CI is a legitimate outcome of violating a design rule.
• You want architectural enforcement with no production dependency — a decisive advantage for teams that refuse to add runtime libraries for code-quality concerns.
• You are willing to pin a version and accept a low-bus-factor dependency: ~200 stars and zero known dependents means you are an early adopter, so a fork-and-maintain contingency and a version pin should be part of the adoption plan.

Look elsewhere when:

• There is no static analysis in CI and no appetite to add it; the attributes would be decoration only.
• The codebase is PHP < 8.1, or is a CMS/plugin/WordPress context where the attribute syntax and tooling assumptions don't fit.
• The team's preference is native language features only — readonly, final, enums, and never cover much of the same ground with zero dependency risk, and a strict "no dev-dependency expansion" policy is in force.
• CI runtime is already a bottleneck; adding PHPStan rules to a large repo has a real minutes-per-build cost that must be budgeted.
• The need is runtime enforcement (hostile or untrusted inputs, serialization boundaries). Static analysis cannot substitute for validation there.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a free, MIT-licensed, developer-only package that lets our engineers write down design rules — "this object can't be changed after creation," "this function has no side effects," "instances are only built this way" — and have our automated code checks fail any pull request that breaks them. It adds nothing to the shipped product: no runtime dependency, no performance cost, no new attack surface, and it can be removed without touching application code. The business case is defect prevention and review efficiency in our most bug-prone layer (business logic and data modeling), not new functionality. Cost is roughly one engineer-day to pilot and a small, ongoing CI-time increase. Primary risk is maturity — it is a small, single-maintainer open-source project with few public users — mitigated by pinning a version, piloting on one bounded module, and the fact that the attributes are inert if we ever walk away.

For engineering — the short version: Add dave-liddament/php-language-extensions as a require-dev dependency plus its PHPStan extension. Start with one high-value attribute (#[Immutable] or #[Struct]) on the value-object layer in a single bounded context, at the lowest PHPStan level that flags violations, and ratchet from there. The attributes are plain PHP #[Attribute] classes — no runtime behavior, no magic — and the enforcement lives entirely in the analyzer, so the blast radius is limited to CI configuration. Expect an afternoon of setup and a short period of triage as pre-existing violations surface; that triage list is itself a useful inventory of design debt. Recommended guardrails: pin the exact version, scope the initial rollout to new code or one module, and record the adopted conventions in the ADR so the reasoning survives the tool.