Package Laravel Package

Getting Started

Install and confirm it actually registers.

composer require mazarini/package
php artisan list | grep -i mazarini

Most Mazarini packages are small utility packages that ship an Artisan command via package auto-discovery. Before assuming the command exists, verify two things:

1. vendor/mazarini/package/composer.json contains an extra.laravel.providers entry. If it does not, add the provider to bootstrap/providers.php (Laravel 11+) or config/app.php (Laravel 10 and below) manually.
2. vendor/mazarini/package/src/ — open the command class directly. This package has ~2 stars and no dependents, so its README is not a reliable API contract. The source is.

Where to look first: the command class's $signature and handle() method. That tells you in thirty seconds whether it reads composer.json, composer.lock, or shells out to composer. That single detail determines most of the gotchas below.

First use case: you are inheriting a Laravel app with 140 packages in composer.json and you need to answer, for a handful of suspicious ones, "who actually pulled this in, and can I delete it?" Run the package's listing command and cross-reference against composer why <vendor/package>. If the package's output gives you the reason annotation in one pass instead of one composer why call per package, that is the entire value proposition — evaluate it on that basis.

Implementation Patterns

Pre-upgrade dependency audit. Before a major composer update, capture current state so you can diff intent:

php artisan <package-command> > storage/app/audit/packages-before.txt
composer update --dry-run

Then compare after. This is the highest-value day-to-day pattern because it turns an opaque lockfile into a reviewable artifact you can attach to a PR.

Deletion safety check. When trimming composer.json, do not remove candidates based on "nothing imports it." A package can be installed solely because another package requires it, or because a Laravel service provider it registers is doing work you never call directly. Use the tool's requirement output to distinguish direct requirements (safe to consider removing) from transitive ones (removing them just means the parent re-adds them, or worse, a runtime class_exists check silently changes behavior). Confirm with:

composer why-not vendor/package
composer depends vendor/package

CI reporting. Wire the command into a scheduled job rather than a per-commit one — package graph churn is weekly, not per-push. Emit to a log or artifact:

Schedule::command('<package-command>')->weekly()->appendOutputTo(storage_path('logs/packages.log'));

Do not make it a merge-blocking check. It has no stable output contract and you will spend more time pinning golden files than getting value.

Team documentation generation. For onboarding docs, run the command and hand-curate the top ~20 packages into a "why we depend on this" table. The auto-generated output is too verbose to commit verbatim; the curated table is the artifact that survives.

Wrap it, don't extend it. If you need structured output (JSON, filtering by reason), write a small command of your own that calls this one's logic or shells out to composer show --tree, and keep the package as a human-facing convenience only.

Gotchas and Tips

• composer.lock must exist and be current. If the package reads the lockfile, a stale lock (common in library repos or after a partial composer update package/x) gives you answers about a dependency graph that no longer exists. Run composer update --lock or a full composer install first.
• Dev vs. production split. require-dev packages and their subtrees are usually reported together with production dependencies. If you are auditing what ships to production, filter out dev requirements — either via the command's options (check --help) or by cross-referencing composer install --no-dev --dry-run.
• replace and provide are the classic blind spot. Packages that are replaced (e.g. symfony/polyfill-*, or laravel/framework replacing many illuminate/* components) will either be missing from the output or appear with a confusing reason. If something you know is installed doesn't show up, check replace in the root composer.json and in laravel/framework's manifest.
• Large output is unwieldy. Pipe to a file and grep rather than scrolling. If the command truncates, check for a --no-truncate-style flag or a config value in config/mazarini.php (publish with php artisan vendor:publish --tag=mazarini if that tag exists — inspect the provider's boot() to confirm the tag name; do not guess it in a script).
• Low-maintenance-burden posture. Two stars, zero dependents, single maintainer, LGPL-3.0. Pin the version explicitly in composer.json ("mazarini/package": "1.0.*" rather than ^1.0) and treat its output as advisory, never as an input to automated deletion. LGPL is fine for linking in a proprietary app; if you fork and modify it, the modified library itself stays LGPL — keep the fork in a separate package rather than pasting the code into app/.
• Laravel version drift. Check the package's composer.json constraints against your framework version. Small packages like this often lag a major release behind. If auto-discovery silently stops working after an upgrade, the provider class likely still exists but its constructor signature broke — the error surfaces on php artisan list, not on install.
• The honest alternative. composer why <pkg>, composer depends <pkg>, composer show --tree, and composer outdated --direct already cover 90% of this ground with a maintained tool you already have. Adopt this package only if its "reasons for installing" annotation genuinely saves you per-package lookups — and if it does, consider writing the ~40-line Artisan wrapper around composer why yourself. You would own it, it would never break on a Laravel upgrade, and you would not be one abandoned repository away from a dead command in your schedule.