Phpstan Nette Laravel Package

Product Decisions This Supports

• Framework-fit triage (the first decision): despite the "Laravel/PHP" framing, this package is a Nette Framework extension for PHPStan — it has zero Laravel surface area. The immediate product decision it supports is "are we a Nette shop, a Laravel shop, or a hybrid?" If the answer is Laravel-only, this package is out of scope and the equivalent investment is larastan/larastan; if there is Nette code in the portfolio (legacy app, acquired service, admin panel), this package is the correct quality tooling for that surface.
• Build vs. buy for static analysis: the alternative to adopting this is hand-writing PHPStan stubs, custom @method/@property docblocks, and type-narrowing helpers for Nette's magic (createComponent*, getByType(Foo::class), getValues($asArray), Html dynamic methods, SmartObject properties). That is ongoing maintenance with no product differentiation — a clear "buy" (and it's free/MIT, dev-only).
• Definition of Done / CI gating: decides whether "new code passes PHPStan at level X with the Nette extension" becomes a merge requirement, and whether the framework-specific rules (rules.neon) are enabled in the blocking pipeline or advisory-only.
• Tech-debt and migration roadmap: quantifies how much type ambiguity exists in presenter/control/form code — useful evidence when scoping a modernization effort (e.g., Nette → Symfony/Laravel rewrite, or Nette 3 → 4 upgrade). It is a measuring instrument during migration, then a decommission item afterward.
• Use cases worth funding: DI container misuse (getByType/createInstance returning wrong types), untyped component lookup in presenters, form value arrays with wrong shapes, missing exception rethrows (e.g. AbortException), invalid regex passed to Nette\Utils\Strings, and use of deprecated Nette\Object. These are exactly the classes of bug that escape code review and surface as 500s in production.
• Risk acceptance: it is a dev dependency with no runtime footprint, so the "blast radius" decision is limited to CI time and false-positive noise — not to production behavior.

When to Consider This Package

Adopt when all of the following hold:

• A meaningful share of the codebase is Nette Framework (presenters, controls, DI container, forms, Nette\Utils), ideally Nette 3/4.
• The team already runs PHPStan 2.x; this extension's major versions track PHPStan majors, so pin them together.
• You can install it as a require-dev dependency and wire it via phpstan/extension-installer (one line) or a manual extension.neon include; rules.neon opt-in separately so the stricter framework rules can be trialed before they block merges.
• You have someone who owns the PHPStan baseline — otherwise new framework rules will land as a wall of errors and the tool gets disabled.

Look elsewhere (or skip) when:

• The stack is Laravel. Use larastan/larastan instead; this package will provide only Nette\* symbols that don't exist in your codebase. Do not add it "just in case" — it adds CI surface for zero signal.
• You are pre-PHPStan as an organization: the sequencing decision is "adopt PHPStan (likely at a modest level) first," then framework extensions, then stricter rules. Buying the extension before the base tool is a false start.
• You need runtime guarantees (e.g., verifying DI wiring actually resolves). Static analysis won't replace container compile checks or integration tests.
• Maintainability risk tolerance is very low and the codebase is Nette-only but small: the ecosystem signal here is thin (≈118 stars, and the dataset shows 0 recorded dependents), so weigh that against the fact that it is published under the PHPStan org with a steady release cadence (2.0.x line through mid-2026, frequent patch releases for PHPStan compatibility, PHP 8.4 deprecation fixes) — active maintenance, but a narrow audience. Expect to pin versions and budget a small upgrade task whenever PHPStan bumps majors.
• You want a single tool for both framework types: there is no unified extension; a hybrid Nette+Laravel monorepo needs both extensions, scoped per-path in separate PHPStan configs.

How to Pitch It (Stakeholders)

One-liner: a free, dev-only PHPStan add-on that teaches our static analyzer how Nette's "magic" works, so type errors in presenters, DI lookups, forms and string utilities are caught in CI instead of in production.

For executives: zero license cost (MIT), zero runtime risk (dev dependency only), and a small, bounded integration effort (composer require + one config include). The payoff is defect prevention in exactly the areas where Nette hides types from the analyzer — DI resolution, component factories, form value arrays — plus guardrails against deprecated patterns and swallowed exceptions. Success is measured in reduced type-related incidents in Nette services, lower baseline error counts over time, and faster onboarding of engineers who can't hold Nette's magic conventions in their heads.

For engineering: one command, composer require --dev phpstan/phpstan-nette, then either rely on phpstan/extension-installer or add vendor/phpstan/phpstan-nette/extension.neon to the config; add rules.neon when ready. It gives correct types for Container::getComponent() and $component['name'], getByType(Foo::class), getValues()/getUntrustedValues() shapes, Strings::match/matchAll array shapes and replace callback types, lookup()/getPresenter()/getSession() nullability, Html dynamic methods, and SmartObject magic properties — all things PHPStan cannot infer on its own. Ship it in advisory mode first, publish the error count, then ratchet to blocking.

The caveat to state up front, not bury: if this assessment is being made in service of a Laravel roadmap, the recommendation is no-go on this package and yes to Larastan; this extension belongs in the plan only for as long as Nette code remains in production, and should carry an explicit decommission date tied to that migration.