Installer Laravel Package

Getting Started

Before you install anything, check the constraints. This package was last released in May 2021 and the repository is archived. That means no Laravel 10/11 support guarantees, no security patches, and no upstream fixes. Confirm the composer.json constraint against your Laravel version before adding it; if you're on a modern Laravel, expect to either pin older framework versions or fork the package.

Minimal steps to evaluate it:

1. Add it as a dev dependency rather than a production one — installers are a setup-time concern:

   composer require --dev package-wizard/installer
   

2. Let Laravel discover the service provider (or register it manually in config/app.php if auto-discovery is disabled).
3. Find the commands it registers:

   php artisan list
   

   Look for the wizard namespace (typically package-wizard:* or a per-package install command). Don't guess the signature — read php artisan help <command>.
4. Run the installer against a package that ships wizard steps, on a disposable branch or fresh clone.

Where to look first: the package's service provider (it's the entry point that registers commands and the install-step hook), then the README for the exact artisan command name, then the source of the commands themselves. The public API surface here is small — a provider hook plus a set of interactive prompts — so reading the provider tells you most of what you need.

First use case: installing a third-party Laravel package whose README says "run the wizard" instead of listing five manual vendor:publish and migrate commands. The value proposition is exactly that: one command replaces a checklist. If the package you're installing doesn't ship wizard steps, this library does nothing for you.

Implementation Patterns

As a consumer (you're installing someone else's package):

• Treat the wizard as a guided vendor:publish + migrate runner. Run it on a clean working tree, then git diff to see exactly what it touched — published config, migrations, assets, and any provider edits.
• Answer prompts deliberately. Interactive installers often branch on your answers (e.g. "publish config? yes/no"), so a rushed Enter-Enter-Enter can skip a step you needed. Read each prompt.
• Verify after: check config/, database/migrations/, and public/vendor/ for the expected artifacts, then run php artisan migrate yourself rather than trusting the wizard's migration step blindly.
• Do setup locally and commit the results; don't run interactive installers on production or in deploy scripts.

As a package author (you're shipping wizard steps):

• Register your install steps through the provider hook the package exposes. Keep each step small and single-purpose: publish config, publish assets, run migrations, seed defaults.
• Make every step idempotent. Users will re-run the wizard after a failed install or an upgrade. Use --force semantics carefully, guard against re-publishing over user-modified config, and never blindly re-seed.
• Order steps by dependency: config first, then migrations, then seeders. A seeder that reads config will fail if config hasn't been published yet.
• Prompt only for things you genuinely can't default. Every question is friction; a sensible default plus a "press Enter to accept" is better than a required free-text answer.
• Keep destructive operations (dropping tables, overwriting files) behind an explicit confirmation prompt, and print what you're about to do before doing it.

CI and automation: interactive prompts read from STDIN, so anything non-TTY will hang or fail. Don't put wizard commands in CI pipelines or container entrypoints. If you need reproducible setup, replicate the wizard's steps as explicit vendor:publish --tag=... and migrate calls in your provisioning script, and reserve the wizard for human-driven local setup.

Gotchas and Tips

• Archived status is the headline. No fixes for new Laravel versions, PHP 8.x deprecations, or Symfony Console changes. Budget for a fork or vendor it into your repo (repositories with a VCS entry) if you depend on it.
• Not a production dependency. Keep it in require-dev. Shipping an archived interactive installer to end users means shipping unmaintained code that runs arbitrary setup logic on their machines.
• Non-interactive contexts break. Pipes, CI, Docker builds, and artisan calls from scripts will fail or block on prompts. Add a guard or skip the wizard entirely outside a real terminal.
• Re-runs are the common failure mode. The second run of a wizard is where non-idempotent steps surface: duplicate migrations, overwritten config, double-seeded data. Always test "run twice" before trusting a wizard-driven package.
• Check what it assumes about discovery. If auto-discovery is off, the provider must be registered manually — a silent no-op command usually means the provider never loaded. Confirm with php artisan about or by dumping registered providers.
• Config caching bites. Run php artisan config:clear before and after installing; a cached config can mask newly published config values and make the wizard look like it did nothing.
• Debug with verbosity. Use -v / -vvv on the artisan call to see which publish tags and migrations actually execute. That's the fastest way to tell whether a step was skipped or silently no-op'd.
• Extension point is the provider hook. If you're forking or authoring, that's where custom steps go — keep your additions there rather than patching the package's command classes, so future (hypothetical) updates are easier to merge.
• Security posture. An interactive installer that publishes files and runs migrations executes code on your machine with your credentials. Read the install steps of any package before running its wizard, especially from unfamiliar vendors.
• Alternatives exist. For most day-to-day needs, a documented sequence of vendor:publish --tag=..., migrate, and a README checklist is more predictable, more CI-friendly, and doesn't depend on an archived package. Reach for this only when a package you actually use ships wizard steps you want to follow.