Laravel Revive Laravel Package

Getting Started

• Install as a dev dependency: composer require --dev devanoxltd/laravel-revive. This package is a tooling package, not a runtime library — never install it in production.
• Let auto-discovery do its job: The service provider is registered via Laravel's package discovery, so no manual providers entry is required. If you have composer.json extra.laravel.dont-discover populated, add the package explicitly.
• Read the README first for the exact command name. The package exposes a publishable config (typically php artisan vendor:publish --tag=revive-config) and likely an install/setup artisan command (e.g. php artisan revive:install). Confirm the tag/command name in the README before running anything — tags for low-adoption packages are the most common source of confusion.
• First use case: scaffold the configs in a fresh or existing Laravel app, then run the wrapped tooling (vendor/bin/pint --test, vendor/bin/phpstan analyse, etc.) to see what the Devanox standard flags. Treat the first run as a report, not a fix.
• Where to look in the repo: src/ (service provider + any console commands), config/revive.php (defaults, tool paths, rule sets), and the published config in your app. The provider tells you exactly which files get written and where.
• Sanity check: php artisan about or php artisan list should show any registered commands; composer show devanoxltd/laravel-revive confirms the installed version.

Implementation Patterns

• Dedicated baseline PR: On an existing codebase, run the tooling once and commit the resulting fixes in a PR titled "apply standard linting" with zero functional changes. Keep it separate from feature work so git blame stays useful and reviewers aren't drowning in whitespace.
• CI as the source of truth: Add a job (GitHub Actions, GitLab CI, Bitbucket Pipelines) that runs the tooling in check-only mode (--test / --dry-run). Developers run the fixer locally; CI enforces. This is the pattern that actually keeps a standard from drifting.
• Pre-commit / pre-push hooks: Wire the fixer into CaptainHook, Husky, or a lefthook config so staged files are formatted before commit. Keep the full analysis (PHPStan level, etc.) on pre-push or CI — running a deep static analysis on every commit is too slow.
• Editor integration: Point IDE-PHP or VS Code at the same ruleset the package publishes. If the package wraps Pint, the IDE should use Pint's binary with the published pint.json. Mismatched editor and CI rulesets is the #1 cause of "works on my machine" formatting drift.
• Layered configs in monorepos: Publish per-application (e.g. apps/api/pint.json) while keeping the package's defaults as the shared root. Override only what differs from the Devanox standard.
• Progressive adoption with baselines: For PHPStan/PHP_CodeSniffer, generate baseline files (--generate-baseline) so the standard only fails on new violations. This lets you adopt without a mega-PR.
• Composer scripts: Add "lint": "vendor/bin/pint --test" and "lint:fix": "vendor/bin/pint" to composer.json so the same commands work locally and in CI. Wire the same into your composer test or composer ci alias.
• Containerized CI parity: Install via composer install --dev in CI images so the versions of the wrapped tools match local. Pinning the package version pins the toolchain.

Gotchas and Tips

• Low adoption = pin the version. With ~10 stars, 0 dependents, and a fast-moving release cadence, treat this as an internal-standard package rather than a settled piece of the ecosystem. Pin with ~x.y in composer.json and read the changelog before bumping. A breaking change in a rule set can produce hundreds of diffs across your repo.
• Dev dependency leakage: composer install --no-dev in production should exclude the package. Verify your Dockerfile uses --no-dev and that composer.lock's dev section is what you expect. A linter in a production image is dead weight at best.
• Existing config wins: If your app already has pint.json, phpstan.neon, .php-cs-fixer.php, or .editorconfig, the package's publish command may either refuse to overwrite or silently overwrite. Check --force semantics and diff before committing. Consider backing up existing files first.
• Config cache: After publishing or editing the config, run php artisan config:clear. If you use config:cache in local dev, published config changes won't take effect until cleared — a classic "I changed the rule and nothing happened" moment.
• First run diff is huge and noisy: Expect whitespace, trailing commas, import ordering, and declare(strict_types=1) additions across every file. Run the fixer, commit the mechanical changes, and then run static analysis so real issues aren't buried.
• Git hooks aren't installed automatically: Publishing a hook config doesn't register it. Run the hook installer (vendor/bin/captainhook install, husky install, etc.) and document it in your onboarding README. New team members will silently skip formatting otherwise.
• Tool binary paths: If the package assumes vendor/bin/<binary> but you install it globally or in a different layout (e.g. DDEV, Sail, Laradock), commands in composer scripts may fail. Use @php vendor/bin/... in composer scripts so the PHP interpreter matches the app.
• Sail / Docker: Run the tooling inside the container (./vendor/bin/sail pint or docker compose exec app vendor/bin/pint). Running on the host can pick up a different PHP version and produce formatting or analysis differences vs CI.
• Debugging the ruleset: If a rule looks wrong, first determine whether it comes from the package's defaults or your published config. Inspect config/revive.php in vendor/devanoxltd/laravel-revive/ and compare to your app's published copy. --diff --verbose on Pint, or -v on PHPStan, usually reveals which layer applied the rule.
• Extension points to lean on: Published config files, environment variables the provider reads, and the underlying tool's own extension mechanisms (Pint presets, PHPStan custom rules, Rector sets). If the package doesn't expose a config value you need, prefer overriding the underlying tool's config over forking the package.
• Version compatibility: Check the README for the supported Laravel/PHP matrix. Because rule sets evolve, a package version built for Laravel 11 may assume declare(strict_types=1) conventions your Laravel 10 app doesn't follow. Match versions deliberately.
• Don't fight it in generated code: vendor/, storage/, and generated directories should be excluded in the tool config. If they aren't, add them — don't let the fixer rewrite bootstrap/cache or compiled views.
• Escape hatch: Keep the ability to git revert the standard-application commit as a single unit. If it goes wrong, reverting one commit is far easier than unpicking hundreds of small formatting edits.