Laravel Revive Laravel Package

Product Decisions This Supports

• Build vs buy for developer experience. The real decision isn't "adopt this package" — it's "standardize linting/standards via a shared preset, vendor a third-party preset, or keep per-repo configs." This package is the cheapest way to prototype option two.
• Quality-baseline standardization across a Laravel portfolio. If the org runs multiple Laravel services, one pinned preset reduces per-repo drift and config bikeshedding — the package's core promise.
• CI/CD and onboarding investment. A shared preset shortens time-to-first-PR and simplifies pipeline setup; the business case is measured in review-cycle time and onboarding days, not features.
• Dependency governance / supply-chain gating. With 10 stars, 0 dependents, and a single maintainer, this also triggers a "may we take this into build pipelines?" policy decision — a useful forcing function for defining a minimum bar for dev-only dependencies.
• Use cases where it fits today: greenfield Laravel apps, agency/client work shipping fast, internal tools, and teams that want an opinionated default rather than a debated one.
• Roadmap placement: belongs under platform/DevEx or engineering-enablement OKRs, never under customer-facing feature roadmaps. Zero runtime footprint means it should not consume product capacity beyond an evaluation spike.

When to Consider This Package

Consider it when:

• You want an opinionated, batteries-included preset and are comfortable accepting Devanox's judgment as the default.
• You're standardizing several Laravel repos and would rather pin one preset than copy pint.json/phpstan.neon files around.
• Your PHP/Laravel version matrix is confirmed compatible — verify explicitly and pin the version; release cadence and support breadth are unproven.
• You intend to fork or vendor it. MIT license plus config-only scope makes a fork cheap and gives you permanent control.
• You want a low-commitment trial: dev dependency, no runtime impact, revertible in one branch, evaluable in a single sprint.

Look elsewhere (or build in-house) when:

• Maturity signals matter. 10 stars, 0 dependents, one maintainer — treat it as a well-packaged template, not a supported product. Don't put it on a critical path without a fork.
• Regulated or enterprise supply chain. No evidence of security review, SBOM, support SLA, or release policy; a one-page internal config file wins the audit conversation.
• You already have strong conventions (PHP CS Fixer, Biome, ESLint presets, a tuned Larastan baseline). You'll be fighting the preset rather than benefiting from it.
• You need framework-agnostic linting or a multi-language monorepo standard — this is Laravel-specific by design.
• You need deep, tuned static analysis. An opaque rule set is worse than a curated in-house baseline you understand line by line.
• Nobody will own upstream review. If you can't commit to reviewing changes each release, you can't adopt it responsibly.

Decision gate: one-sprint spike on two representative repos. Measure setup time, CI duration delta, and style-related PR comments before vs. after. Adopt only if it beats the status quo and an owner is named for the fork.

How to Pitch It (Stakeholders)

Executives (1–2 slides): This is a small, free, development-only package that applies a shared code-quality and linting baseline to our Laravel services. Expected payoff is lower review friction, fewer style debates, and faster onboarding — not new customer features. Risk is contained: it never ships to production, is removable in one commit, and is MIT-licensed so we can fork it under our org. The caveat is maturity — early-stage project, essentially one maintainer — so the recommendation is to fork and pin rather than consume it directly. Ask: 1–2 engineer-days for evaluation and a fork, plus a decision on whether to standardize across Laravel repos.

Engineering (working level): It's a preset that wires Devanox's linting and standards config into a Laravel app. Treat it as config-as-code: pin the version, vendor or fork it, and review the rule set before rollout so we own the diff. Benchmark against plain Pint/Larastan defaults, confirm PHP/Laravel support fits our matrix, and check CI runtime/caching impact. Abandonment risk is real but non-fatal — the fork and our own config keep working if upstream disappears.