Weave Code
Survey Lib Bundle Laravel Package
sst/survey-lib-bundle
SST Survey Lib Bundle is a PHP/Symfony package that brings reusable survey components into your application, offering structures for surveys, questions, and responses so teams can add survey creation and management features without building the core survey logic from scratch.
A Symfony Bundle for developing surveys
Frequently asked questions about Survey Lib Bundle
- Can I install sst/survey-lib-bundle in a Laravel application with Composer?
- Composer may resolve the package, but it will not boot in Laravel. The package is packaged as a Symfony Bundle, which relies on a Bundle class, a DependencyInjection Extension, compiler passes, and bundles.php registration inside a Symfony kernel. Laravel has no bundle loader and discovers packages through extra.laravel.providers and a ServiceProvider. A literal composer require typically installs code that Laravel never wires up.
- Why doesn't sst/survey-lib-bundle auto-discover in Laravel like other packages?
- Laravel package discovery reads the extra.laravel.providers key in composer.json and boots a ServiceProvider against Laravel's container. A Symfony Bundle instead registers through bundles.php and its own Extension and services.yaml files. Without a hand-written Laravel ServiceProvider bridging the survey services, nothing in the bundle is registered, routed, or made available to your application.
- What license is sst/survey-lib-bundle released under?
- The repository is flagged as NOASSERTION, meaning GitHub could not identify an OSI-standard license. For a package you intend to embed in a product, that is a legal stop-the-line item rather than a footnote. Read the actual LICENSE file in the repository and have counsel confirm compatibility with your distribution model, SaaS or on-prem, before committing any engineering effort.
- Does sst/survey-lib-bundle use Doctrine entities, and can Eloquent consume them?
- Symfony bundles of this type typically ship Doctrine ORM entities and repositories, and those cannot be consumed by Eloquent without an adapter layer. The alternative is running doctrine/orm alongside Eloquent through a Laravel Doctrine bridge, which adds significant operational weight for a single survey feature. If the persistence layer is Doctrine-bound, expect to rewrite models and migrations in Eloquent or wrap them carefully.
- Does the survey domain logic live in the bundle or in a separate core library?
- This is the single most important question to resolve before planning a build. If the meaningful survey logic lives in an underlying framework-agnostic library that the bundle merely wires up, feasibility in Laravel improves substantially. If the domain model sits in the bundle glue itself, integrating it means effectively forking the package and owning that fork.
- Which Symfony and PHP versions does the bundle require, and will that conflict with Laravel?
- A Symfony bundle usually declares constraints against symfony/framework-bundle, symfony/form, symfony/twig-bundle, doctrine/orm, and a specific Symfony major version. Laravel 10 and 11 ship Symfony components but not framework-bundle, so constraint conflicts are likely during installation. Expect to inspect composer.json closely and possibly use --ignore-platform-reqs during a spike, which is not a production solution.
- Is sst/survey-lib-bundle actively maintained?
- The signals are weak: around 8 stars, zero dependents, a single maintainer, and an overall health score of 0.23. The high opportunity score likely reflects an underserved domain niche rather than package maturity. Treat a single-maintainer repository with no dependents as code you will own, and review commit cadence over the last 24 months before relying on it.
- Are there tagged releases, a changelog, and a test suite for this survey bundle?
- The available metadata does not evidence a tagged release, changelog, or test suite, so verify each one in the repository. For a package that would sit under your survey feature, the absence of tests means you inherit all verification burden. Check for open issues and pull requests that suggest abandonment or unresolved security concerns as well.
- What are the alternatives to adopting a Symfony survey bundle in Laravel?
- The realistic options are evaluating the bundle's domain model as a reference implementation, wrapping a standalone core library if one exists, or reimplementing surveys in Laravel with Eloquent models, migrations, policies, and Blade views. If you only need surveys, questions, responses, and versioning, a native Laravel implementation is usually smaller than adapting Symfony forms, Twig, routing, and security. Choose based on your reporting and audit requirements, not on the package name.
- How should I prototype a Laravel integration before committing to it?
- Run a throwaway spike: install into a scratch Laravel app, inspect composer.json for hard dependencies like doctrine/orm and symfony/framework-bundle, and confirm whether the survey logic is standalone. Write a minimal ServiceProvider to see how much of the bundle actually functions outside Symfony. Resolve the license question first, because no engineering effort should be committed until the LICENSE file is cleared.
Weaver
How can I help you explore Laravel packages today?