Laravel Devtools Laravel Package

Getting Started

Start by installing it as a dev-only dependency so it never reaches production:

composer require --dev alireza-h/laravel-devtools

The package is small (23 stars, MIT, last released August 2023), so treat the source itself as the primary documentation rather than expecting a full docs site. Your first three steps after install:

1. Confirm the service provider registered. Check bootstrap/cache/packages.php or run php artisan about and look for the package entry. If it's not listed, the package may rely on manual registration — inspect vendor/alireza-h/laravel-devtools/composer.json for the extra.laravel.providers key.
2. Run php artisan list and compare against your baseline. Most "devtools"-style packages surface value through extra artisan commands, so the new entries are your entry point.
3. Look for a published config. If vendor/alireza-h/laravel-devtools/config/ exists, publish it with php artisan vendor:publish --provider="AlirezaH\LaravelDevTools\..." (verify the namespace in src/), then commit the config so the whole team shares defaults.

First real use case: wire it into your local workflow only — typically a debugging/inspection helper during feature development, or a scaffold/command you run once per new model or module. Get one command working end-to-end on a throwaway branch before adopting it team-wide.

Implementation Patterns

Environment-gated registration. Because it's a dev tool, wrap any manual registration in a guard so CI and production never load it:

// app/Providers/AppServiceProvider.php
public function register(): void
{
    if ($this->app->environment('local', 'testing')) {
        $this->app->register(\AlirezaH\LaravelDevTools\DevToolsServiceProvider::class);
    }
}

If the package auto-discovers via composer.json, use composer install --no-dev in production builds and verify with php artisan about on the deploy target.

Local vs. shared config. Keep the published config file in version control, but override per-developer settings through .env rather than editing the config directly. This is the cleanest integration point for anything like output verbosity, cache paths, or command enablement flags.

Pair with your existing debugging stack. For most teams this package overlaps with Telescope, Ray, or Laravel's built-in dd()/dump() helpers. The pragmatic pattern is:

• Use it for the specific thing it does better (fast command output, one-off inspections), and
• Don't let it become a second, competing debugging surface. Pick one primary tool per concern.

Use it in tests sparingly. If the package exposes assertions or helpers, they belong in feature tests only where they reduce boilerplate. Don't let dev-tool behavior leak into test assertions about business logic — those tests should pass with the package removed.

Wrap third-party calls behind your own helper. Since maintenance is uncertain, isolate any package API you rely on behind a small class or trait in app/Support/. If you later drop the dependency, you change one file.

Gotchas and Tips

Pin the version and audit compatibility. Last release is August 2023, so Laravel 11/12 and PHP 8.3+ compatibility is not guaranteed. Before adopting:

composer require --dev alireza-h/laravel-devtools:^1.0
composer why-not alireza-h/laravel-devtools

Check the require block in vendor/.../composer.json for illuminate/* and php constraints. If it caps at ^10.0, either don't adopt it or fork and bump the constraint — do not use --ignore-platform-reqs on a shared project.

Auto-discovery leaks into production. This is the most common mistake with devtool packages. If you see it in php artisan about on staging, either move to require-dev + --no-dev builds or add an explicit dont-discover entry in your root composer.json:

"extra": {
    "laravel": { "dont-discover": ["alireza-h/laravel-devtools"] }
}

Then register manually behind the environment guard above.

Low adoption means thin error messages. With 23 stars, obscure failures are unlikely to be answered on StackOverflow. Debug by reading the source directly — the whole package is probably a few files in vendor/alireza-h/laravel-devtools/src/. Set a breakpoint or dd() inside the service provider's boot() to confirm it's running and what it registers.

Config cache surprises. After publishing config, php artisan config:cache will freeze it. In local dev, run php artisan config:clear after edits — and remember that a cached config from a previous environment can make commands behave oddly. If something "works in tinker but not in a command," suspect the config cache first.

Commands are the extension point. If the package adds artisan commands, the commands themselves are usually the stable API — not internal classes. Build your own thin wrapper commands that call them if you need custom arguments, rather than extending vendor classes that may change between releases.

Watch for global helpers and side effects. Devtool packages sometimes register global functions or facades in boot(). Grep for function_exists, class_alias, and Blade::directive in src/ before installing on a large codebase — name collisions with your own helpers are painful to trace.

Have an exit plan. Given the stale release cadence, assume you may need to remove it within a year. Keep the usage footprint small, document in your README why it's there and what it replaces, and prefer using it for developer convenience over anything a CI pipeline depends on.