Laravel Db Tools Laravel Package

Getting Started

Given the package has zero stars, zero dependents, and its last release was March 2023, treat this as internal/experimental tooling from Portable Studios rather than a community-supported package. The first thing you should do is read the source, not the docs.

1. Install and discover:

   composer require portable/laravel-db-tools
   php artisan list | grep -i db
   

   Laravel's package auto-discovery should register the service provider. If no commands appear, inspect composer.json for extra.laravel.providers and register manually in config/app.php.

2. Look here first on GitHub:

   • src/Console/ or src/Commands/ — the actual artisan commands are the real documentation
   • config/ — publish with php artisan vendor:publish --tag=db-tools (verify the tag by reading the service provider)
   • README.md — check the repo, not Packagist, which is stale

3. First use case: Almost certainly one of the classic "DB tools" jobs — dump/backup a database, restore a snapshot, or anonymize/fake data for local and staging environments. Pick the safest read-only command (typically a dump or "list" command) and run it against a local sqlite or a throwaway MySQL instance before pointing it at anything real.

4. Sanity-check compatibility: The package predates Laravel 11. Confirm the illuminate/support constraint in its composer.json allows your Laravel version; if not, expect to fork.

Implementation Patterns

Because this is a low-signal package, the patterns below assume a typical DB-tools shape — verify each against the actual command signatures in src/.

Schedule routine dumps in a dedicated command, not in Kernel::schedule directly. Wrap the package command in a thin app-level command so you control logging and failure handling:

// app/Console/Commands/BackupDatabase.php
protected $signature = 'app:db-backup';
public function handle(): int
{
    $this->call('db:dump', ['--connection' => config('database.default')]);
    $this->info('Backup complete');
    return self::SUCCESS;
}

Then in routes/console.php (Laravel 11+) or app/Console/Kernel.php:

$schedule->command('app:db-backup')->dailyAt('02:00')->onOneServer();

Environment-gate destructive commands. Anonymization and restore commands should refuse to run in production unless an explicit --force flag is passed. Check whether the package already does this; if not, wrap it:

if (app()->isProduction() && ! $this->option('force')) {
    $this->error('Refusing to run in production without --force');
    return self::FAILURE;
}

CI/CD integration. For restore/seed workflows in CI, invoke the package command from your pipeline script after migrations, pointing at the CI database via --connection. Keep connection credentials in the pipeline's env vars, not in config/database.php.

Config publishing over config editing. Publish the config once (php artisan vendor:publish) and commit it, so environment-specific overrides live in your app's config tree rather than in vendor/. This survives composer update.

Fork-and-own if you depend on it. With zero dependents and a 2023 release, the realistic pattern is: vendor the package into app/ or an internal namespace, then maintain it. Don't build critical backup logic on top of an unmaintained dependency you can't patch.

Gotchas and Tips

• Stale dependency constraints. A March 2023 package will likely cap illuminate/* at ^10.0. Test on your actual Laravel version early; if Composer refuses, use php artisan tinker against a forked copy rather than forcing --with-all-dependencies on the original.

• Auto-discovery may silently fail. If commands don't show in php artisan list, the service provider isn't registered or the command classes aren't in the expected Console/Commands namespace. Check php artisan about and the package's src/ layout.

• Config cache hides changes. After editing the published config, run php artisan config:clear. With config:cache active, env() calls inside the package's config will return null — a common footgun in vendor configs.

• Debug artisan commands with verbosity and exception traces. php artisan db:dump -vvv surfaces what the package is actually executing (often a shell call to mysqldump/pg_dump). If the binary isn't on PATH in your runtime (e.g. a container or cron job with a minimal env), the command fails opaquely.

• Credential exposure via shell. DB tools that shell out to mysqldump often interpolate credentials into the command string. Confirm the package doesn't pass passwords via -p<pass> on the argv (visible in ps); if it does, patch it to use MYSQL_PWD or a defaults file.

• No upstream support means no CVE coverage. Given the release date and adoption, assume any bug you hit won't be fixed upstream. Before shipping, grep for exec(, shell_exec(, Process::run, and direct DB::statement calls to understand the blast radius.

• Extension points are uncertain — read the code. If the package offers a DbTools::extend() or driver interface, great; if not, the pragmatic extension point is subclassing the command and registering yours instead of the vendor one via $this->app->extend in a service provider.

• Lock the version exactly. "portable/laravel-db-tools": "1.0.0" (or whatever the actual tag is) rather than ^1.0, so a surprise release doesn't change command behavior underneath your scheduled backups.