Dev Tools Laravel Package

Getting Started

• Install as a dev-only dependency: composer require --dev soyhuce/dev-tools. This package is tooling for your local/CI workflow — it should never end up in a production composer install --no-dev build.
• Look first at three places: composer.json (require/extra.laravel.providers to confirm auto-discovery), the package README for the exact command names it exposes, and vendor/soyhuce/dev-tools/src/ to see the service provider and any console commands it registers.
• If the package ships configuration, publish it before doing anything else: php artisan vendor:publish --tag=dev-tools-config, then commit config/dev-tools.php so the whole team shares the same settings.
• First use case: on a fresh checkout, run php artisan list and look for the command namespace the package registers, then run its main entry point once against your app to confirm the wiring works before adding it to scripts.
• Upgrade check for this release: 4.1.0 only extends the test matrix to Laravel 12 — no source changes, no new config keys. A composer update soyhuce/dev-tools from 4.0.0 should be a no-op for your code.

Implementation Patterns

• Composer scripts as the front door. Expose the package through named scripts ("lint", "check", "fix") rather than letting each developer memorize raw invocations. New team members then only need to know composer check.
• CI parity. Run the exact same script locally and in CI (composer check in both). This is where a dev-tools package pays for itself — one definition of "green" instead of two drifting ones.
• Pin uniformly. Use ^4.1 in every repository so a Laravel 12 app and a Laravel 11 app still get the same toolchain behaviour. Since 4.1.0 is additive, the constraint bump is safe to roll out in bulk.
• Keep it out of application code. Don't reference package classes from app/ or from runtime service providers. If you need shared behaviour (e.g. a base test case or a custom rule), extend it in your own tests/ or app/Support/, not by reaching into vendor/.
• Docker/Sail: because it's a composer dev dependency, it is already inside the image if you install with dev deps. Add a sail composer check alias so containerized and host-based developers behave identically.
• Framework-upgrade workflow: this release is a good template — bump the package, verify Laravel 12 in CI, then bump the app. Do the package bump before the framework bump so tooling never blocks the upgrade.

Gotchas and Tips

• Don't ship it. Verify with composer show --direct --no-dev or by building a --no-dev image; a stray require instead of require-dev will pull the whole toolchain into production.
• Conflict resolution on Laravel 12. If Composer refuses, the blocker is usually another dev package, not this one. Run composer why-not soyhuce/dev-tools 4.1.0 to identify the real constraint before resorting to --ignore-platform-reqs.
• Auto-discovery needs a refresh. After install or upgrade, php artisan package:discover (or a plain composer dump-autoload) will pick up provider changes; a stale bootstrap/cache/packages.php is the classic "command not found" cause.
• Config caching in local dev. A leftover bootstrap/cache/config.php from a config:cache run will hide your edits to the published config. php artisan config:clear is the first debugging step, always.
• Read the major-version boundary. 4.0.0 was a major and may have altered defaults or dropped older Laravel versions; if you are coming from 3.x, read the 4.0.0 changelog before the 4.1.0 one, which is purely a support-matrix addition.
• Extension points: published config file for behaviour, and the package's service provider for container bindings — prefer config overrides where they exist, since bindings can be silently overwritten by a later provider.
• Silent no-ops. Tooling commands often exit 0 while doing nothing (e.g. no files matched, paths misconfigured). When results look suspiciously clean, run the underlying tool directly with verbose output to confirm it actually scanned your source.