stickee/canary
Canary is a Laravel package for feature flags and gradual rollouts. Define features in config, enable them for users, groups, or a percentage of traffic, and use simple runtime checks to ship safely and roll back quickly.
Architecture fit. Unchanged in substance. Canary remains developer-experience tooling — a bundled static-analysis and linting baseline (PHP_CodeSniffer rulesets, PHPStan/Larastan configuration, Pint/Rector presets, Composer/CI scripts) — and belongs in require-dev with no production runtime, database, or queue surface. The v4.0.1 release does sharpen one aspect of the fit question: the changelog entry "Require updated Larastan config" (SC-1885) confirms the package does not merely invoke Larastan but owns and constrains its configuration. That moves Canary further from "thin wrapper" toward "opinionated baseline with a version coupling," which strengthens the case that the decision is really about whether we adopt Stickee's curated standard or vendor equivalent configs ourselves.
Integration feasibility. Still mechanically simple — a composer require --dev plus config inheritance and CI wiring. The one new integration nuance is that a patch-level release changed the required Larastan configuration, which means bumping Canary's pin can change analysis output. Integration effort should therefore include a per-bump diff review of the resulting violation set, not just a dependency update. The one-time remediation burst estimate stands.
Technical risk. The release partially answers the provenance question and leaves the core risk intact. Positives: there is a tagged, semver-ordered release history (v4.0.0 → v4.0.1), the maintainer is shipping readme and config work tracked against internal ticket IDs (SC-1885), and the project appears actively staffed. Negatives: both "new contributors" are Stickee staff handles, so the external contributor base remains zero and the bus factor is unchanged — the project is healthy only insofar as Stickee continues to fund it. Contributor rotation is a subtler signal: two first-time contributors at the 4.0.x line suggests staff churn on the project, which is fine while it lasts and risky at handover. The earlier anomaly around release-date metadata can be largely retired now that a coherent sequential tag history is visible, though exact tag dates should still be confirmed. Secondary risks stand: opinionated defaults encoding another company's conventions, and tight constraints on PHP/Laravel/PHPStan/Larastan that will lag our upgrade cadence.
Key questions.
larastan/larastan version range, require a host-supplied config shape, or ship the config wholesale? This determines whether Canary can block a Laravel upgrade.Stack fit. Unchanged: appropriate for Composer-managed Laravel projects already committed to static analysis in CI; a poor first foray into static analysis, and a poor fit for polyglot or non-Laravel PHP estates.
Migration path. Evaluation-first, adoption-second, as before. The spike now has an additional output: capture the violation report at a pinned Canary version and at the version you would realistically bump to, so you can see how much drift a patch bump introduces. If the "legitimate bugs caught" category is thin, vendor the configs into an internal standards repo and take ownership — the package's value is its configuration content, and the 4.0.1 changelog reinforces that the config, not the code, is the product. If the yield is substantial and override semantics are clean, move to a single-team pilot.
Compatibility. Verify PHP minor, Laravel major, PHPStan major, and now explicitly Larastan version, since the release indicates a hard coupling there. Use composer why-not in a scratch branch before rollout. Because 4.0.1 changed a required config, test the upgrade path from whichever version you would start on to the latest, rather than only testing a clean install.
Sequencing.
Maintenance. Low while pinned, but the 4.0.1 release demonstrates the specific mechanism of future pain: a patch-level change to bundled Larastan configuration can alter results or force a local config migration. Budget for reading release notes on every bump, and retain the fork option — MIT licensing makes it legal, but a fork transfers the ruleset and dependency-graph ownership to us, which is the work we were trying to avoid.
Support. No commercial support, no SLA, no external community. The release notes reinforce this: contributors are Stickee employees working internal tickets. Failures surface as blocked pipelines rather than outages, which is tolerable for dev tooling and not tolerable if the standard becomes a mandated gate across many repositories without a named internal owner.
Scaling. Config drift remains the scaling problem. Exact version pins per repository plus a governed bump cadence are now more clearly necessary, because a single upstream patch can change analysis behavior for every consumer. A wrapper package is a net positive at scale only under central governance.
Failure modes.
Ramp-up. Minimal for engineers fluent in PHPStan and PHP_CodeSniffer — roughly a day to read the config and run the scripts. The non-obvious cost is acculturating the team to this ruleset's opinions, especially where the 4.0.x line diverges from community defaults; without rationale documentation, unfamiliar failures read as tooling bugs. Given near-zero external adoption and a maintainer base that is entirely one vendor's current staff, plan for self-sufficiency from day one: read the source, expect to maintain a fork, and treat Canary primarily as a curated reference implementation of Laravel static-analysis practice rather than a durable third-party dependency.
How can I help you explore Laravel packages today?