Canary Laravel Package

Product Decisions This Supports

• Build vs. buy vs. "borrow the pattern": Canary is not a library that ships runtime features — it is an opinionated distribution of lint/static-analysis configuration for Laravel. The real decision it informs is whether to standardize code-quality tooling as a first-class internal product (a shared preset package) or leave each team to assemble PHP-CS-Fixer/Pint, PHPStan/Larastan, and CI wiring on their own. Canary is a working existence proof of the first option, in the same lineage as laravel/pint presets or opinionated dev tooling from the Spatie ecosystem.
• Engineering enablement / DevEx roadmap: Supports a roadmap line item for "quality gates as a product" — a single-command composer require plus composer lint experience for every Laravel service. This is a platform-team play, not a feature-team play, and should be prioritized against other DevEx investments (CI speed, scaffolding, local environment tooling).
• Standards governance and scope of enforcement: The existence of a shared preset forces an explicit decision on how much enforcement is non-negotiable (formatting, dead code, type coverage) versus advisory. That is a policy decision with real cost implications (blocked merges, false positives, developer friction), and it needs a PM-level owner rather than emerging ad hoc from a CI config.
• Onboarding and time-to-first-PR: For an agency or multi-repo org, a preset package directly compresses new-engineer and new-repo setup time — a metric worth tracking and worth spending platform capacity on.
• Risk/compliance posture: Static analysis tiers map onto security and audit narratives (SAST-adjacent controls, dependency hygiene, code review evidence). Framing lint gates as a control helps justify the cost in regulated or enterprise contexts.
• Build/borrow signal from the ecosystem: The package's profile — single-digit stars, zero dependents, single-org authorship — is itself decision-relevant data. It suggests the pattern is underexploited in the Laravel ecosystem and that a well-maintained equivalent is a genuine gap, not that this specific package is an adoption candidate.
• Make-vs-maintain (reinforced by v4.0.1): The latest release is a maintenance patch whose headline change is requiring the updated Larastan config. That is the clearest possible demonstration of the hidden cost in the "adopt it" path: a preset package is a thin shim over upstream tools, so every Larastan/Pint config-schema change becomes a mandatory, coordinated bump across every repo that pinned the preset. If we build our own preset we own that upgrade treadmill — but we also control its timing, testing, and rollout. That ongoing cost (small but permanent) is the true comparison point against buying a commercial alternative (PHPStan paid tiers, hosted code-quality SaaS) and against simply adopting upstream Pint + Larastan directly.
• Release cadence as a health signal: v4.0.1 shows the project is alive and responsive, but also that its releases are driven by internal need (the changelog cites an internal ticket, SC-1885). Useful, but not evidence of external-consumer support.

When to Consider This Package

Reasonable to evaluate when:

• You are a Laravel-centric organization with several (roughly 5+) repositories and no consistent lint/static-analysis baseline.
• You want the speed of a pre-curated config and are willing to accept someone else's opinions on rule sets, PHP version targets, and directory conventions.
• You are specifically copying the approach as a reference implementation: read the composer.json and config stubs, then fork or re-implement internally.
• Your stack matches the author's assumptions (recent Laravel, PHP 8.x, standard app//tests/ layout) so the presets do not fight your structure.

Look elsewhere — or build — when:

• Dependency risk matters. Low star count, zero dependents, and a single organizational owner (both v4.0.1 "new contributors" carry the same org handle) mean no community bus factor, no ecosystem pressure to keep it current, and no guarantee of semantic versioning.
• You are not the originating org. The description literally scopes it to "Stickee Laravel projects." Presets encode house conventions (naming, namespaces, test layout, tolerated legacy patterns) that will not transfer cleanly, and the maintainers have no incentive to support outside use cases.
• You need release-note-driven confidence. v4.0.1 adds no capabilities, no deprecations, and no breaking changes — it is a README edit plus a config-requirement bump. That is fine for a healthy internal tool, but it means you cannot read the changelog to understand upstream version compatibility; you have to read the config diff.
• You need portability. Non-Laravel PHP, polyglot monorepos, or mixed JS/PHP services get nothing from a Laravel-specific wrapper.
• You can get 80% of the value in a day. laravel/pint plus larastan/larastan plus a checked-in phpstan.neon and a CI job is a well-trodden path with excellent documentation and first-party backing. The wrapper's marginal value is convenience, not capability.
• Compliance or procurement review is required. An unmaintained-risk, low-adoption MIT package is a hard sell in a vendor-risk process when the underlying tools are already approved.

Default recommendation (unchanged after v4.0.1): do not adopt as a dependency; treat as a design reference and build a thin internal preset (or adopt Pint + Larastan directly) with an owner, a changelog, and a deprecation policy. If you use it as a blueprint, copy the pattern of pinning to upstream config versions — that is exactly what v4.0.1 does — but plan for that bump work to land in your own backlog.

How to Pitch It (Stakeholders)

To executives (one paragraph): Our Laravel teams currently choose their own code-quality tooling, which means inconsistent standards, slower onboarding, and reviewers spending time on formatting instead of product logic. A shared "quality preset" package — a single install that wires up formatting and static analysis for any Laravel repo — is a small, low-cost platform investment that standardizes the baseline, shortens new-repo and new-hire ramp-up, and turns code review attention back to design and risk. We have a credible reference implementation to copy from; the recommendation is to build a thin internal version rather than take an external dependency, so we control upgrades and support. Success looks like: reduced review cycle time, fewer formatting/nit comments, and measurable ramp time for new services.

To engineering leadership: This is a ~1–2 day spike plus ongoing light ownership. It replaces N bespoke CI configs with one versioned preset, lets us ratchet static-analysis strictness over time per repo (baseline-then-tighten), and gives us a single lever for PHP/Laravel upgrades. The upstream package's most recent release is a maintenance patch that exists solely to pull in an updated Larastan config — which tells us the useful work is the pin-and-bump discipline, not the code itself. We can own that discipline ourselves: preset pinned to upstream Pint/Larastan releases, one bump PR, one changelog entry, no inherited single-maintainer dependency.

To engineering teams: One composer require --dev, one command, deterministic output in CI and locally. No lock-in: the preset is a thin config layer over tools you already know, and any repo can opt out or override per-rule. Expect initial churn as we tune rules against existing code; we'll start advisory-only and gate progressively. When upstream tools change their config format, we'll batch the upgrade on our own schedule rather than inheriting someone else's release timing.