Larastan Config Laravel Package

Technical Evaluation

What the package actually is: stickee/larastan-config is not a library — it is a distributed configuration artifact. It packages an opinionated phpstan.neon (Larastan bootstrap, rule level, ignore-error patterns, likely parameter overrides) for consumption via Composer in require-dev. There is no runtime code path, no service provider, no public API surface. That materially simplifies the evaluation: the question is not "is this good software" but "is this configuration worth inheriting."

Architecture fit: Fit is binary and cheap to test. Any Laravel application already running PHPStan/Larastan can consume it via an includes: directive. Because it is dev-only, it cannot affect production request handling, queue workers, or deployment artifacts. It slots cleanly into the "static analysis gate" layer of CI. Fit degrades the moment your project layout, namespace conventions, or Laravel major differ from Stickee's own baseline — which is the near-certain case for an external adopter.

Integration feasibility: Mechanically trivial (one composer require --dev, one includes: line). Strategically weak. The package encodes another team's tolerance for false positives, their ignoreErrors patterns, and their directory assumptions. Those are the highest-judgment, least-transferable parts of a static analysis setup. The transferable value is the rule selection and level — and that is readable in five minutes from the .neon file without taking a dependency.

Technical risk: Blast radius is low — failures manifest as red CI, not incidents — but vendor risk is high relative to the signal available:

• 0 stars, 0 dependents, no downstream validation. Nothing here has been exercised outside the author's repositories.
• Single-organization provenance. The package exists to serve Stickee's monorepo hygiene; external users are incidental.
• Config packages are a SemVer hazard. A rule-level bump or a tightened ignoreErrors is a legitimately "patch" change that will break every consumer's build simultaneously.
• The release date (2026-08-26) on a package with no community traction suggests automated tagging rather than curated, documented releases.
• Loose Composer constraints are common in packages like this, which can silently resolve a PHPStan/Larastan combination the config was never authored against.

Key questions for the maintainer (or to answer by reading the repo):

1. What Larastan/PHPStan major versions are constrained, and are those constraints tight or permissive?
2. Does the shipped config contain ignoreErrors patterns or a bundled baseline — and if so, what classes of defect do they suppress?
3. Are absolute paths, namespace roots, or module directories hardcoded, or is everything relative and overridable?
4. Is the rule level set, and can a consumer raise it without forking?
5. What is the release policy — does a version bump ever ship a stricter ruleset?
6. Does it assume a Composer plugin allow-list entry, a specific PHP minor, or a CI-specific bootstrap file?

Integration Approach

Stack fit: Composer-based Laravel (9/10/11+) on PHP 8.1+, with PHPStan and Larastan already present or added alongside. Works uniformly in GitHub Actions, GitLab CI, Bitbucket Pipelines, and local vendor/bin/phpstan analyse. No Docker, database, or service dependency. The only coupling is the version triad: Laravel major → Larastan major → PHPStan major.

Migration path (recommended, two-track):

1. Track A — reference, not dependency. Clone the repo, read the .neon, extract the rule level, the Laravel-specific extensions, and the ignore-pattern taxonomy. Author an in-repo phpstan.neon.dist you own. This captures ~90% of the value at zero vendor risk and is the recommendation given the 16.67 score and zero dependents.
2. Track B — dependency, only if justified. Fork the repo into your own org, tighten the Composer constraints, and publish internally (private Packagist / VCS repository). This preserves upstream-tracking convenience while giving you control over release cadence, which the upstream will not provide.

Compatibility: Validate before adopting rather than after. Run composer why phpstan/phpstan and composer show larastan/larastan against the package's declared constraints; a conflict here is the single most likely integration blocker and it surfaces in minutes. Then run the suite at your existing level and diff the error count — a jump in either direction is a signal worth understanding.

Sequencing:

1. Inventory current state: existing ruleset, current error count, whether a baseline is in use.
2. Sandbox on one low-risk service; run the external config non-blocking in CI.
3. Triage the delta — new findings (good, adopt selectively) versus newly suppressed findings (bad, reject that subset).
4. Merge the accepted subset into your owned config.
5. Add a baseline for legacy debt, then turn the job blocking.
6. Ratchet the level upward on a schedule; regenerate the baseline downward as debt is retired.

Operational Impact

Maintenance: The artifact itself is near-zero maintenance. The recurring cost is the upgrade treadmill: every Laravel major bump forces a Larastan bump which forces a PHPStan bump which forces a config review. As a dependency, that review happens on Stickee's schedule, not yours — and Stickee has no incentive to prioritize your Laravel version. Forking converts an uncontrollable dependency into a controllable one at the cost of a periodic upstream diff.

Support: No SLA, no documentation beyond the repository, no community to escalate to at 0 stars / 0 dependents. MIT licensing is the real support contract here: the guaranteed remedy is "fork it." Budget accordingly — do not route this through a procurement or vendor-review process, and do not let it become a single point of failure for CI.

Scaling: This is the package's genuine strength. A shared config is how you get uniform analysis standards across thirty repositories without thirty bespoke .neon files. The inverse is the risk: one upstream change propagates to every consumer at once. Mitigate with exact version pinning plus Dependabot/Renovate in review-required mode, and roll upgrades through a canary repo before fleet-wide adoption.

Failure modes:

Ramp-up: The config is a 20-minute read for any engineer who knows PHPStan. The real ramp-up is workflow literacy — understanding baselines, regenerating them, and knowing when an ignore pattern is legitimate versus debt-hiding — roughly half a day for the team, and worth doing regardless of whether this package is adopted.

TPM recommendation: Do not adopt as an external dependency. Consume it as a reference implementation, lift the rule selection into an internally owned config, and treat the 16.67 score and zero dependents as an accurate read: no evidence of external validation, no support surface, and no reason to accept upstream release cadence for an artifact you can reproduce in an afternoon.