Commands Laravel Package

Getting Started

Assess before you adopt. This is a zero-star, zero-dependent package with a one-line Dutch description ("Verschillende handige commands" — "various handy commands"). That description is the whole spec: it is a grab-bag of Artisan commands, not a cohesive feature package. Treat onboarding as an audit, not an install-and-go.

Minimal steps:

1. Install into a scratch branch, not main.

   composer require marshmallow/commands:^1.3 --dev
   

   Start with --dev even if you eventually need it in production: you have not yet established which commands are safe to run against live data. Target ^1.3 because v1.3.0 is the only release with a confirmed PHP 8.4-compatible codebase; anything older may emit deprecation noise in your logs on 8.4.

2. Read composer.json in vendor/marshmallow/commands/ first. Look at three keys:

   • extra.laravel.providers (or aliases) — this tells you whether commands are auto-discovered or you must register the service provider yourself.
   • require — the Laravel/Illuminate version constraints. v1.3.0 fixed a PHP 8.4 PHPDoc deprecation only; that is evidence the author runs modern PHP, not evidence the illuminate/* range was widened. Confirm it declares support for your Laravel major; an unconstrained or stale range is still your main upgrade risk.
   • autoload.psr-4 — the root namespace, which is what you will grep for in step 3.

3. Enumerate what you actually got.

   php artisan list | grep -i marshmallow
   

   If nothing appears, auto-discovery failed or the provider is not listed — open src/ and locate the *ServiceProvider.php, then read register() and commands([...]) to see the exact signatures. This is the single most important file in the package; everything else follows from it.

4. Read every command class before running any of them. In a package this size there are likely a handful of classes under src/Commands/. For each, check $signature, then scan the handle() body for unlink, truncate, delete, DB::statement, exec, shell_exec, or calls to external HTTP endpoints. Anything destructive or network-bound goes on your "never in production" list now, not later.

5. First real use case: run the read-only candidates against a local or staging database as a one-off diagnostic — cache clearing, storage/queue inspection, environment dumps, log tailing are the typical inhabitants of a package like this. Pick one command that replaces a manual chore you already do weekly, prove it on staging, and leave the rest uninstalled or unregistered.

If step 3 or 4 turns up nothing legible — no README, no docblocks, unclear destructive behavior — the correct assessment is to skip the package and copy the one or two command bodies you want directly into app/Console/Commands/. At this dependency count the package is a convenience, not a platform.

What v1.3.0 changed (and did not). The release is hygiene only: a dependabot.yml, an actions/checkout bump from 2 to 4, and a PHP 8.4 PHPDoc deprecation fix. No new commands, no signature changes, no removals, no runtime behavior changes. Read it as two signals: the maintainer is reachable and CI is now kept current, but no functional feature work is landing. Your command audit from v1.2.x carries over unchanged — you do not need to re-audit handle() bodies when bumping 1.2.x → 1.3.0, only re-run your integration tests.

Implementation Patterns

Cherry-pick rather than adopt. Because the commands are unrelated, the most valuable pattern is selective registration: in your own AppServiceProvider::register(), register only the specific command classes you have vetted, and prevent the package's provider from auto-loading if it registers everything unconditionally. Many packages expose this via a config flag; if this one does not, you can fork it into app/Console/Commands/ and drop the dependency entirely.

Wrap, don't call directly. For anything you run repeatedly, add a thin first-party command that delegates:

protected $signature = 'ops:nightly-report';
public function handle(): int
{
    $this->call('the-package-command', ['--flag' => true]);
    $this->info('done');
    return self::SUCCESS;
}

This gives you a stable name you control, a place to add guards and logging, and an easy migration path if the package is abandoned.

Schedule with environment gates. If a command belongs in routes/console.php or Kernel::schedule(), wrap it:

$schedule->command('the-package-command')
    ->dailyAt('02:00')
    ->environments(['production'])
    ->withoutOverlapping()
    ->onFailure(fn () => Log::error('pkg command failed'));

withoutOverlapping() matters more than usual here: you do not know whether the author wrote re-entrant code.

CI usage for read-only commands. Commands that only inspect state (config dumps, version checks, environment sanity) are good candidates for a deploy pre-flight step. Use --no-interaction and assert on the exit code — check the handle() return value first, because packages of this vintage often return; (implicit null, coerced to success) instead of return self::SUCCESS.

Config publishing, if offered. If the provider calls publishes([... => config_path('marshmallow.php')]), publish and commit it, then read every key. Undocumented config keys are where the surprising behavior lives — particularly anything defaulting to "all" or "true" for a destructive scope.

Test your integration, not the package. Use Laravel's command test helpers to lock in the behavior you depend on:

$this->artisan('the-package-command')->assertExitCode(0);

This is your regression net for the next composer update, which is the only realistic way you will notice upstream breakage in a package with no dependents and no issue traffic. The 1.2.x → 1.3.0 bump is a good argument for this pattern: the changelog reads as a no-op, and only your tests can confirm that for the command you actually use.

Pin to the minor you tested. Use "marshmallow/commands": "1.3.*" rather than ^1.0. Dependabot-driven repos produce frequent patch/minor PRs that are mostly CI churn; a narrow constraint keeps your composer.lock diff small and reviewable so the one substantive bump does not hide inside noise.

Gotchas and Tips

• Zero dependents is a signal, not proof of badness. It means nobody has hit the edge cases for you. Pin the version ("marshmallow/commands": "1.3.*" or exact), commit composer.lock, and read the diff on every bump. Do not use a floating ^ constraint on a package with no downstream pressure to keep BC.

• Active CI is not active development. v1.3.0 contains no feature work — only a Dependabot config, a workflow action bump, and a PHPDoc fix. Dependabot opening PRs and a maintainer merging them does not mean issues get triaged or destructive-command bugs get fixed. Weigh the dependency on that basis.

• PHP 8.4 deprecation noise is now fixed — but only in v1.3.0+. On 8.4, older versions can flood storage/logs/laravel.log with PHPDoc-related deprecations that mask real errors. If you are on 8.4 already, the bump is worth taking purely for log hygiene; if you are on 8.1–8.3, it changes nothing for you.

• Command name collisions. Utility packages love short, generic signatures (app:clear, db:reset, make:report). php artisan list will show you duplicates. If two commands share a signature, the later-registered provider wins silently and you will debug the wrong class for an hour. Check php artisan list output before and after install.

• Cached config and discovery. After install, run php artisan optimize:clear. Then confirm bootstrap/cache/packages.php lists the provider. A stale packages cache is the #1 cause of "the commands don't show up."

• Production safety is on you. There is no evidence of a confirmation prompt in a package this obscure. Before any scheduled or manual production use, wrap destructive calls with $this->confirm() in your own wrapper, or gate the schedule behind an env check. Never run an unfamiliar command as a smoke test against a database you care about.

• Debug with verbosity, not dd(). Run php artisan <cmd> -vvv to surface the underlying exception. If the command swallows exceptions in a bare try/catch, temporarily override in a subclass or fork the class and add report($e).

• Check output and exit codes. Commands that echo instead of $this->info() and return void will break && chains in shell scripts and onFailure hooks in the scheduler. Normalize this in your wrapper by returning an explicit Command::SUCCESS/FAILURE.

• Extension points are probably absent. With this scope, expect no interfaces, no events, no manager class — just concrete command classes. The practical extension point is subclassing: class SafeClear extends \Marshmallow\Commands\ClearCommand and overriding handle(). If the internals are private, fork instead of fight it. Note that subclassing a class whose only recent change was a PHPDoc edit is low-risk; subclassing is more stable here than in a package with active refactors.

• Vendor audit checklist before go-live: license file present and MIT as declared; no post-install-cmd scripts in composer.json; no outbound HTTP in any command you register; no eval, no base64 blobs; no telemetry. If any of those fail, copy the code you need into your own namespace and drop the dependency — at zero dependents you lose nothing. The new dependabot.yml does not change this checklist, but it is a cheap re-check: confirm it configures only the composer/actions ecosystems and does not add credentials or registries.

• Have an exit plan. Budget the cost of removal as the cost of a git mv vendor/marshmallow/commands/src/Commands app/Console/Commands/Legacy/ plus a namespace rewrite. If that feels expensive, you are leaning on the package too hard for something with no maintainer signal behind it.