Setup Bundle Laravel Package

Technical Evaluation

Recommendation up front: no-go as a dependency. The scoring (0.4) reflects an abandonment profile, not a quality judgment, and the material available does not even establish which framework the package targets. Treat it as a design reference, not a library to install.

Architecture fit — unresolved, and that is disqualifying on its own.

• The package name orkestra-cms/setup-bundle, the repository description ("easy setup of new Symfony projects"), and the -bundle suffix all point to a Symfony Bundle (a Bundle subclass plus a DependencyInjection/Extension).
• description.md describes a Laravel package — Artisan commands, vendor:publish, service providers, migrations and seeders.
• These are mutually exclusive extension models. Until that contradiction is resolved, we cannot state the integration surface, the entry points, or the runtime contract. Any estimate is fiction.

Integration feasibility — effectively zero against a current stack.

• Last release 2017-11-13 places the supported window at roughly Symfony 3.x or Laravel 5.4/5.5.
• On Laravel 9+ the illuminate/* constraints will fail Composer resolution outright; even forced, 2017-era PHP against 8.0–8.3 hits removed constructs (curly-brace offsets, each(), create_function()) and 8.2 dynamic-property deprecations.
• On Symfony 5+ the bundle plumbing changed materially, and Flex recipes — first-party, maintained, and integrated with the installer — already own this exact problem space.
• Verify in ten minutes before anything else: composer require --dry-run against our real lock file. That single command likely ends the evaluation.

Technical risk.

• Unmaintained + unaudited transitive dependencies. A 2017 dependency graph cannot be cleared by composer audit in any meaningful sense: no upstream will ship the fix, and the package will pin us to old versions of packages we do care about.
• The automation is the dangerous kind. "Migration and seed orchestration" and "environment checks" run mutating operations. Without source review we cannot confirm idempotency, transactional wrapping, or a production guard. A setup tool that seeds into a live database is a data-loss vector, not a convenience.
• Zero dependents and zero stars mean no field reports, no community patches, no issue triage, and no prior art for edge cases — we would be the first, and only, integration test.
• Documentation is not trustworthy. The supplied assessment-laravel_dev.md is generic boilerplate (vendor/package, "a 1.0.0 release", Package::fake()), none of which is grounded in this repository. Combined with the framework contradiction, this reads as generated rather than authored against the source. Do not let a README claim substitute for reading the service provider / Bundle class.

Key questions (owner or maintainer — some may be unanswerable, which is itself the answer).

1. Is this Laravel (service provider + Artisan) or Symfony (Bundle + DI Extension)?
2. What exact framework and PHP versions did the 2017-11-13 release target?
3. Does a port exist for Laravel 10+/Symfony 6+ on any branch or fork?
4. Are migrations and seeds idempotent, and does the installer refuse to run outside local?
5. What is the license, and are we free to fork and vendor the code internally?
6. Which stack was this actually used on, and by whom? Zero dependents suggests "never in anger."

Integration Approach

Stack fit: conditional and probably negative. This is a fit only if we are operating a Symfony 3/4 or Laravel 5.4/5.5 estate. On any modern target — Laravel 11/12 or Symfony 6/7 — fit is zero and no adapter layer rescues it.

Migration path: do not migrate to this. Migrate the idea out of it.

• The genuine value is the checklist: publish config → publish assets → migrate → seed → assert environment prerequisites. That is a few hundred lines of orchestration around first-party primitives.
• Symfony target: a Flex recipe plus a thin bin/console app:install command. Recipes are the sanctioned mechanism and carry no maintenance burden.
• Laravel target: a single php artisan app:install command in our own app, or an internal Composer package of type library with a tagged vendor:publish group. Either is ~1–3 engineer-days.
• Salvage from the repository only if the source is readable: the ordering, the predicate checks, and the idempotency guards. Reimplement those; do not import them.

Compatibility gates, in order — each is a kill switch.

1. composer require --dry-run orkestra-cms/setup-bundle against our lock. Resolution failure ends it.
2. Read composer.json: framework constraints, PHP constraint, extra.laravel / extra.symfony discovery blocks, and whether a LICENSE exists.
3. Read the entry class (Bundle or ServiceProvider) to settle the Laravel/Symfony question definitively.
4. Grep for migrate, seed, db:, and any env guard before allowing it near a shared database.
5. Only then: a one-day timeboxed spike on a scratch branch, against a throwaway database, wired into exactly one command — never into CI or a deployment pipeline.

Sequencing. Ambiguity resolution (10 min) → dependency spike (1 hr) → go/no-go decision → if go, in-house reimplementation behind a config flag → internal publish and runbook. The decision review should happen before any engineering time is committed beyond the spike.

Operational Impact

Maintenance: we inherit 100% of it on day one. An eight-year-dormant package with no security response process becomes our fork the moment it lands in composer.json. Budget for it as owned code, not as a dependency — and at that point, owning a small purpose-built installer is strictly cheaper than owning someone else's stale one.

Support: none. No vendor, no active maintainer, no issue triage, no upgrade path. Every future question ("why did seeding double-insert?") is answered by whoever on our team reads the source. That cost is invisible in a PoC and permanent in production.

Scaling. Setup tooling is dev-time and CI-time only, so it does not touch runtime throughput. The scaling risk is organizational: if the installer is referenced in onboarding docs, gold images, or environment provisioning, a broken or incompatible installer blocks every new environment — a single point of failure on the critical path to a working dev box, multiplied by headcount.

Failure modes to design against (assume all are present until proven otherwise).

• Partial migration application with no transactional rollback → half-built schema.
• Non-idempotent seeds → duplicate rows on second run or re-provision.
• Stale published config after any upgrade — published files are copies and will silently drift from package defaults.
• Silent no-op if service-provider or bundle auto-discovery is disabled → "installed but nothing happened."
• Artisan command name collisions with existing application commands.
• The ambiguity failure: an engineer wires Laravel artisan code into a Symfony codebase (or vice versa) and spends a day on a class-not-found.

Ramp-up. Documentation quality is low and demonstrably unreliable, so onboarding cost per engineer is high and non-decreasing. Mitigation if retained at all: write our own runbook, pin the exact commit, vendor the source into an internal repository, and put a README banner stating that upstream is dead. Realistically, that overhead exceeds the value of what is being installed — which is the strongest argument for the in-house build.

Bottom line for the roadmap: reject as a dependency, timebox a one-day salvage review of the orchestration logic, and fund a small first-party setup command instead. Expected cost delta is a couple of engineer-days against an open-ended maintenance and security liability — an easy call to defend to stakeholders.