Installer Laravel Package

Technical Evaluation

Architecture fit. Package Wizard Installer targets a narrow, real seam in the Laravel ecosystem: the post-composer require gap where a package's README tells users to publish config, publish assets, run migrations, seed data, and register a provider. The integration surface is a service-provider hook plus terminal prompts, which is architecturally shallow and low-coupling — a package author declares install steps, the installer sequences them. For a TPM this is attractive because it standardizes onboarding DX without touching runtime application code. It is not framework infrastructure; it is developer tooling with a runtime footprint limited to console commands.

Integration feasibility. Low effort to try, moderate effort to trust. It is a single Composer dependency, MIT-licensed (fork-friendly), and additive — no schema changes, no middleware, no request-path impact. The blockers are lifecycle signals, not design: last release 2021-05-25, repository archived, 62 stars, and a 0.25 quality/adoption score. That combination means the package is effectively unmaintained and we would own it on day one. Any integration decision must assume zero upstream fixes.

Technical risk.

• Framework drift (high). A 2021 Laravel package predates Laravel 9/10/11 baselines, PHP 8.1+ requirements, and the laravel/prompts console UX. Its interaction layer almost certainly uses Symfony Console question helpers that have since changed behavior and deprecation posture. Compatible-version ceilings in composer.json are likely to conflict with current projects.
• Non-interactive environments (high). Interactive wizards are the classic CI failure: prompts block or fail in non-TTY contexts, container builds, and scripted provisioning. If there is no robust --no-interaction path with sensible defaults, this package actively breaks automation.
• Idempotency and side effects (medium). Publishing config and running migrations/seeders as a guided flow risks overwriting customized config on re-run and executing destructive steps without a dry-run. There is no evidence of transactional rollback.
• Abandonment (certain). Archived status is a hard fact, not a risk to be mitigated by monitoring.

Key questions.

1. What Laravel and PHP versions are actually supported, and does it install cleanly on our current LTS?
2. Does it degrade gracefully with --no-interaction, and are defaults safe for CI?
3. Are install steps idempotent, and is publishing guarded against overwriting existing config?
4. Can install steps be exercised in automated tests (e.g., artisan assertion helpers), or is the flow only testable by hand?
5. Is the service-provider hook stable enough to vendor without API churn, given MIT licensing?
6. How many internal packages would actually adopt this versus a first-party install command?

Integration Approach

Stack fit. Reasonable for Laravel 8-era applications; poor fit as a greenfield standard. The package is a developer-experience layer, so it should be scoped to require-dev in package repositories and never installed into production images. It is not a runtime dependency and should not appear in application composer.json requires.

Migration path. Treat this as a pattern to adopt, not a package to adopt. Two viable paths:

• Vendor/fork (recommended if the pattern is valuable). MIT license permits a private fork pinned to our supported Laravel/PHP matrix, with the interaction layer reimplemented on laravel/prompts and the publish/migrate/seed steps made idempotent and flag-driven. Cost is measured in days, not weeks, because the surface area is small.
• Do nothing / reimplement natively (recommended if adoption is limited). A php artisan <vendor>:install command using laravel/prompts plus a documented step contract delivers 80% of the value with zero abandonment risk. Most packages only need publish + migrate + a confirmation prompt.

Compatibility. Gate any evaluation on a spike: install into the current LTS project, run composer why-not against our PHP and Laravel constraints, then exercise the wizard in both TTY and non-TTY contexts. If Composer refuses to resolve, the decision is closed without further analysis.

Sequencing.

1. Two-day spike: dependency resolution, TTY/non-TTY behavior, config-overwrite behavior, test assertions.
2. Decide fork-versus-reimplement based on spike outcome and how many internal packages would adopt the step contract.
3. If proceeding, define the step contract (publish, migrate, seed, post-install hook) and require idempotency plus --no-interaction defaults as acceptance criteria.
4. Pilot with one non-critical internal package, then standardize via a shared internal docs page and a package-author template.

Operational Impact

Maintenance. Ownership transfers to us immediately and permanently. Archived means no security patches, no framework compatibility fixes, and no issue triage. Since it is dev-only tooling, the security blast radius is contained, but supply-chain review still applies if we keep the upstream dependency rather than vendor it. Budget a small recurring allowance for framework-upgrade breakage if we fork, and zero if we reimplement.

Support. Developer-facing support burden is real but bounded: onboarding questions, "the wizard hung," "it overwrote my config." Without upstream docs beyond a README, internal documentation and a troubleshooting section become mandatory deliverables, not nice-to-haves.

Scaling. Compute scaling is irrelevant — it runs once per developer per package install. The scaling concern is organizational: every adopting package inherits the same prompt UX and the same failure surface, so a defect in the wizard multiplies across the package portfolio. Conversely, a well-defined step contract scales DX cheaply and consistently.

Failure modes.

• Prompt hangs or aborts in CI/containers with no TTY — highest-frequency, highest-annoyance failure.
• Partial installs where config published but migrations failed, leaving a package in an ambiguous state with no rollback.
• Silent config overwrite destroying local customization.
• Composer resolution failure on modern Laravel, surfacing as an opaque dependency conflict for package consumers.
• Framework upgrade breakage discovered mid-upgrade, blocking unrelated work.

Ramp-up. Near zero for developers using the wizard — prompts are self-describing. Non-trivial for package authors, who must learn the step contract and, if we fork, the interaction layer. Estimate half a day per package author and one to two days for whoever owns the fork. The dominant cost is not learning the tool; it is accepting the long-term ownership of an abandoned dependency for a convenience-layer problem.