Survey Lib Bundle Laravel Package

Technical Evaluation

Architecture fit — the central problem. sst/survey-lib-bundle is packaged as a Symfony Bundle, not a Laravel package. Those are different extension models:

• Symfony Bundles rely on Bundle classes, DependencyInjection\Extension, compiler passes, Resources/config/services.yaml, and auto-registration via bundles.php in a Symfony kernel.
• Laravel has no bundle loader. It discovers packages through composer.json extra.laravel.providers and boots them through a ServiceProvider against Laravel's container.

So a literal composer require will likely install but not boot. The realistic integration is not "install the bundle" but "extract the survey domain logic and re-wire it into Laravel," which is a materially larger effort than the package name implies. The critical unknown — and the single most important question below — is whether the meaningful survey logic lives in the bundle glue or in an underlying, framework-agnostic library that the bundle merely wires up. If the latter, feasibility improves substantially; if the former, we are effectively forking.

Integration feasibility. Composer installation is technically possible but will surface constraint conflicts, because a Symfony bundle typically declares requirements against symfony/framework-bundle, symfony/form, symfony/twig-bundle, doctrine/orm, and a specific Symfony major version. Laravel 10/11 ship Symfony 6/7 components but not framework-bundle, so version constraints are likely to clash. Expect to inspect composer.json closely and possibly need --ignore-platform-reqs for a spike. Persistence is the second friction point: if the bundle ships Doctrine entities and repositories, those cannot be consumed by Eloquent without an adapter layer or by running Doctrine alongside Eloquent (doctrine/orm + a Laravel Doctrine bridge), which adds operational weight for a survey feature. Templating (Twig vs. Blade), routing, forms, and auth (Symfony Security vs. Laravel guards) are all likely to require replacement rather than reuse.

Technical risk. Three risks are elevated:

1. License is NOASSERTION. GitHub could not identify an OSI-standard license. For a package we would embed in a product, this is a legal stop-the-line item, not a footnote. Until the actual LICENSE file is read and cleared by counsel, no engineering effort should be committed.
2. Adoption and maintenance signal is weak. 8 stars, 0 dependents, an overall score of 0.23. The high "opportunity" score (8.14) likely reflects an underserved domain niche rather than package maturity — opportunity and health are pointing in opposite directions, and health governs procurement. A single-maintainer repository with no dependents is a proxy for "we will own this code."
3. Framework drift. A bundle written for Symfony 3/4-era conventions will age poorly against Laravel 11+ and PHP 8.3+. Every Laravel major upgrade becomes a manual verification exercise.

Key questions to resolve before any build decision.

• What license is actually in the repository, and is it compatible with our distribution model (SaaS vs. on-prem)?
• Does the bundle contain the survey domain model, or only DI/config wiring around a separate core library? Is the core usable standalone?
• Which Symfony and PHP versions are required, and is doctrine/orm a hard dependency?
• Is there a tagged release, a changelog, and any test suite? What is the commit cadence over the last 24 months?
• What is the data model for surveys, questions, responses, and versioning — and does it meet our reporting and audit requirements?
• Are there open issues or PRs indicating abandonment or unresolved security concerns?

Integration Approach

Stack fit: poor as-shipped, moderate as a fork/adapt. I would not frame this as "adopt the bundle." I would frame it as "evaluate the survey domain model as a reference implementation, then decide between wrapping and reimplementing." The bundle itself is unlikely to be a drop-in Laravel dependency.

Recommended migration path (in order):

1. License and provenance review — read the LICENSE file, confirm authorship and any contribution terms. Gate everything else on this.
2. Code audit — separate the reusable domain layer (entities/value objects, survey definition, response capture, validation rules) from Symfony-specific glue (DI extensions, form types, Twig templates, controllers).
3. Feasibility spike (time-boxed, one engineer, ≤1 week) — install into a branch, attempt to instantiate the domain services manually without the Symfony kernel, and persist a survey/response round-trip. The exit criterion is a working survey lifecycle in a Laravel app, not "it installs."
4. Decision gate: wrap, fork, or rebuild. Given the license risk and coupling, "adopt the data model as a design reference and rebuild natively in Eloquent" is a legitimate and often correct outcome — it converts an uncertain dependency into owned, testable code.
5. If wrapping: publish an internal Laravel package with a ServiceProvider, config file, and migrations that mirror the survey schema; write adapters for persistence, authorization, and rendering. Treat the upstream repository as read-only reference code pinned to a specific commit.

Compatibility and sequencing notes. Do the Laravel/Symfony version matrix check in step 3, not later. Assume Doctrine is present until proven otherwise; decide explicitly whether to (a) introduce Doctrine ORM into the Laravel app, or (b) map the schema to Eloquent and drop Doctrine entirely. Option (b) is cleaner operationally but forfeits upstream compatibility. Sequence the front-end and reporting layers after the persistence decision, since they depend on the schema shape.

Operational Impact

Maintenance. Assume we inherit the codebase. With 0 dependents and a low health score, upstream is unlikely to ship fixes, respond to issues, or track Laravel/Symfony releases. Budget ongoing ownership: dependency upgrades, security patching, and schema migrations become our responsibility. If we wrap the bundle, we own a pin to a specific commit forever; if we fork, we own a divergence.

Support. There is no vendor, no SLA, and almost certainly no user documentation beyond the repository README. Internal documentation and a named code owner are prerequisites, not nice-to-haves.

Scaling. The survey workload scales with response volume, which is database-bound. The bundle's scaling characteristics are therefore the ORM's: schema design, indexing on response/survey foreign keys, and pagination in reporting. Doctrine adds a second ORM's worth of memory and query-logging overhead if run alongside Eloquent. Run a load test against the response-write path before committing to the schema — survey traffic is bursty and write-heavy during collection windows.

Failure modes to plan for:

• Silent upstream abandonment — no CVE process, no patching. Mitigation: vendored/forked code, internal security review on a schedule.
• Major-version breakage — Laravel 12 or PHP 8.4 upgrade breaks the wrapper. Mitigation: pinning, integration tests in CI covering the survey lifecycle.
• License challenge post-launch — the most damaging failure mode, since it can force removal of shipped functionality. Mitigation: resolve in step 1.
• Hidden kernel coupling — a service resolves kernel or request_stack at runtime and fails only in production paths. Mitigation: the spike must exercise full CRUD, not just boot.

Ramp-up. A Laravel-only team will need to understand Symfony bundle conventions (DI extensions, compiler passes) to interpret the source, which is a real but manageable cost — days, not weeks, for a senior engineer. The larger cost is institutional: someone must own an unfamiliar, unmaintained dependency. Weigh that against the alternative of designing a survey schema natively, which a competent Laravel team can likely do in comparable time with far less downstream risk.

TPM recommendation. Do not treat the 8.14 opportunity score as an adoption signal. Commission the license review and the one-week spike; treat "rebuild the data model natively" as the default outcome and require the spike to argue convincingly against it.