- What is stickee/canary and what does it do in a Laravel project?
- Canary is a Laravel developer-experience package that bundles an opinionated linting and static-analysis baseline. It packages the rulesets and configuration Stickee applies to its own Laravel projects, most likely combining PHPStan or Larastan, PHP_CodeSniffer and Pint presets with Composer scripts to invoke them. It is intended to be installed as a dev dependency so a team runs consistent quality checks locally and in CI.
- How do I install stickee/canary in a Laravel project?
- Install it as a dev dependency with composer require --dev stickee/canary, then publish or inherit the provided configuration files and wire the supplied Composer scripts into your pipeline. There is no service to provision, no credentials to manage and no data migrations. The real cost is reconciling your existing codebase against the bundled ruleset.
- Does Canary add runtime overhead or production dependencies?
- No. Canary is tooling rather than runtime infrastructure, so it belongs in require-dev and has no production footprint, database surface or queue workers. It cannot affect application availability. Keep it out of production installs by deploying with composer install --no-dev.
- Which static analysis and linting tools does Canary configure?
- It is a curated configuration layer, so it typically configures PHPStan or Larastan, PHP_CodeSniffer and Laravel Pint rather than replacing them. Check the package composer.json to see whether those tools are declared as direct dependencies or expected from the host project, because that determines whether Canary drives your tool versions or merely configures them. If it pins them directly, your upgrade cadence follows the package's.
- Can I override or extend Canary's rulesets for my own codebase?
- Configuration is usually publishable, but the likely intent is wholesale adoption rather than cherry-picking individual rules. Partial override is the difference between a usable baseline and a fork you end up maintaining yourself. Confirm per-project exclusions and rule overrides are supported before you commit to adopting it.
- Which PHP and Laravel versions does stickee/canary support?
- Version support is declared in the package composer.json constraints. Because it is single-vendor and low-adoption, expect the PHP, Laravel and PHPStan constraints to lag behind new framework majors. Verify the declared matrix against your target versions and check the tag history and commit recency before treating it as actively maintained.
- Is stickee/canary actively maintained and safe to depend on?
- Treat it with caution. One star and zero dependents suggest a package published for internal consumption that has not been validated by an external community, and maintenance is discretionary to a single vendor. Confirm real tag history and commit recency, and be prepared to vendor or fork the configs if the repository is archived.
- How do I run Canary in CI, such as GitHub Actions?
- Run the provided Composer scripts as a step in your CI job, ensuring dev dependencies are installed so the analysis tools are present. Most teams add a lint step and a separate static analysis step. The important part is gating the pipeline so violations fail the build rather than being reported and ignored.
- How is Canary different from using Larastan, PHP_CodeSniffer and Pint directly?
- Using the tools directly gives you full control over rules, versions and exclusions, but you must assemble and maintain the configuration yourself. Canary is a shortcut only if its bundled baseline closely matches what you would otherwise hand-build. If your existing baseline differs materially, you will spend more time suppressing rules than configuring them.
- What are the alternatives to stickee/canary for Laravel static analysis?
- The realistic alternatives are assembling your own baseline from Larastan, PHP_CodeSniffer and Pint, or adopting rulesets published by other Laravel consultancies. For a team without an existing analysis gate, a hand-rolled incremental configuration is often safer than a large opinionated ruleset that produces a demoralizing failure backlog on day one.