Laravel Swarm Installer Testkit Laravel Package

Product Decisions This Supports

• Ecosystem quality strategy: Decide whether Laravel Swarm and its companion packages should share a common installer test contract so swarm:install* behavior—config publishing, migrations, prompts, flags, idempotency, and failure modes—stays consistent across packages.
• Build vs. buy/borrow: Choose between maintaining duplicated Testbench scaffolding in every package or adopting a shared MIT-licensed harness. The package is best treated as borrowed internal test infrastructure, not a customer-facing dependency.
• Release gating and compatibility policy: Use the harness to define a CI matrix across Laravel, Testbench, and PHP versions, then block releases when installer regressions appear in supported combinations.
• Roadmap sequencing: Estimate the test cost of adding companion packages or new swarm:install* options. If the harness already covers the installer pattern, roadmap expansion is cheaper and lower-risk.
• Support and onboarding: Reduce maintainer onboarding time and support burden by standardizing fixtures, assertions, and failure output for installer tests.
• Investment tracking: Treat this as an internal platform investment. Measure success through reduced duplicated test code, faster package release cycles, and fewer escaped installer defects—not through stars or end-user adoption.

When to Consider This Package

Consider adoption when:

• You maintain or plan multiple Laravel packages in the Swarm family, each with one or more swarm:install* Artisan commands.
• Current test suites duplicate Testbench bootstrapping, filesystem fixtures, config/publish assertions, command input mocking, or migration checks.
• You need a consistent CI matrix for installer behavior across supported Laravel/PHP/Testbench versions.
• Your team can accept a dev-only, early-stage dependency with low adoption, provided it is pinned, reviewed, and ideally piloted in one package first.
• You are willing to contribute fixes upstream or fork the harness if it becomes strategically important.

Look elsewhere or avoid adoption when:

• You have a single Laravel package or a simple installer where native Testbench coverage is sufficient.
• Your existing installer test suite is already mature, stable, and not meaningfully duplicated.
• You need long-term vendor support, broad community validation, or a formal SLA.
• The project is not Laravel/Testbench-based or the installer behavior is too custom to fit the harness without extensive forks.
• Security or compliance rules prohibit unreviewed test dependencies. In that case, copy the relevant patterns into an internal harness rather than depend on the package.

How to Pitch It (Stakeholders)

For executives: This is test infrastructure for the Laravel Swarm package family. It helps us verify installer commands consistently across companion packages, reducing duplicated QA work and release risk. The license is MIT, so direct cost is low, but the package is early-stage with little adoption. Recommendation: treat it as a pinned development dependency or internal fork after a pilot—not a customer-facing bet. Success should be measured by fewer installer regressions, less duplicated test code, and faster companion-package releases.

For engineering: This package provides a shared Testbench-based harness for swarm:install* test suites, standardizing scaffolding, fixtures, and assertions around publishing, configuration, migrations, prompts, and command flags. Use it in the CI compatibility matrix, pin the version, and be prepared to contribute fixes or fork. Start with one package pilot and compare test runtime and maintenance against the current duplicated setup. Do not couple production code to it; it belongs strictly in development/test tooling.