aidynmakhataev/laravelsurveyjs
Laravel package for integrating SurveyJS: create and manage surveys, store form JSON, collect responses, and retrieve results via Eloquent models and ready-made routes, making dynamic survey forms easy to add to any Laravel app.
Architecture fit. This is a thin Laravel wrapper around SurveyJS, the client-side JavaScript survey/form engine. Its value is glue, not engine: a service provider, publishable config/migrations, a Survey model plus a responses/answers table, a controller for persisting submissions, and a Blade include that drops the SurveyJS JS/CSS into the page. Architecturally that is a natural fit for a Laravel monolith rendering server-side views, because SurveyJS definitions are JSON and map cleanly onto JSON columns plus Eloquent casts. If our application is Inertia/React/Vue or API-first with a separate front end, the wrapper contributes almost nothing — we would install the official survey-core/survey-creator-core npm packages and write our own two endpoints. The honest framing for the team: this package buys roughly one to two days of scaffolding, and we inherit all of its maintenance risk to get it.
Integration feasibility. Composer installation is trivial; the real question is whether the package's illuminate/* and PHP constraints admit our current Laravel version. With a last release of 2021-05-27, it was authored against Laravel 8-era conventions — auto-discovery may work but Blade syntax, config publishing, and any test coverage will not have been exercised against Laravel 10/11/12 or PHP 8.2/8.3. Expect to fork to widen constraints. The bundled SurveyJS assets will also be several major versions behind current SurveyJS, which is a functional and patch-level security gap. That is a front-end swap we can do independently, but it invalidates the "just install it" value proposition.
Technical risk.
NOASSERTION means GitHub could not match an SPDX license. That is frequently "custom terms" or "no license at all," which for a commercial product means no grant to use, modify, or redistribute. Legal review is a hard gate before any spike code reaches a shared branch. Separately, confirm SurveyJS's own tiering — the core form library and creator are open source, but analytics, PDF export, and hosted services are commercial and need keys.Key questions for the spike. What is in the LICENSE file verbatim? What are the exact composer.json PHP and Laravel constraints? Which SurveyJS version is vendored, and is it swappable without touching package code? Does it support arbitrary JSON definitions (the common case) or a fixed question model? How are responses validated server-side — is anything enforced, or does it trust the client? Does it handle multi-tenancy, versioning of survey definitions, and partial/incomplete submissions? Is there any test suite or CI?
Stack fit. Adopt only in a Blade/Livewire monolith that needs a survey capability quickly and has no existing form-builder. In a modern Vite-bundled front end, skip the wrapper: use the official npm packages and write ~150 lines of Laravel for models, routes, and validation. That path is more work upfront and dramatically less risk.
Migration path. Treat the package as a reference implementation, not a dependency. Spike it on a throwaway branch against our actual Laravel version, then decide between three options: (a) adopt as-is — only if it installs cleanly and legal clears the license; (b) fork into our org namespace, pin the SurveyJS version, widen Composer constraints, add tests and CI — the recommended middle path; (c) reimplement the migrations, models, and controller ourselves and pull SurveyJS from npm — recommended if the front end is not Blade. Option (c) is usually a two-to-three-day task and eliminates the dependency entirely.
Compatibility. Verify PHP and Laravel constraints first; then upgrade the client-side SurveyJS assets to a supported release and re-test rendering, theming, and response JSON shape. Do not assume the wrapper's bundled JS is compatible with the SurveyJS schema our content authors will use.
Sequencing.
Maintenance. Assume full ownership. No releases since 2021 means no upstream fixes for Laravel upgrades, PHP deprecations, or SurveyJS CVEs. Budget a recurring line item, not a one-off: at minimum an annual dependency review, plus a bump whenever we move Laravel majors. Because Composer constraints are narrow, this package is a plausible blocker on a future framework upgrade — worth flagging in the platform roadmap even if we adopt it.
Support. No vendor behind the wrapper. SurveyJS commercial support covers SurveyJS products, not this integration. Internal on-call must own rendering failures and submission bugs; there is no upstream to escalate to.
Scaling. Survey definitions are small; response tables are not. A high-traffic survey produces one row per submission with a large JSON payload, plus per-answer rows if the package normalizes them. Plan indexes on survey ID and timestamps, decide early whether analytics run against the OLTP tables or an export, and set a retention/archival policy before the table reaches tens of millions of rows. Rendering scale is a client-side concern: very large surveys degrade in the browser regardless of backend.
Failure modes. Most likely, in order: (1) license ambiguity stalls or kills the project late — resolve first; (2) Composer conflict blocks a Laravel upgrade, forcing an emergency fork; (3) stale SurveyJS assets expose an unpatched XSS or simply cannot render a schema our authors need; (4) vendor:publish overwrites locally customized views or assets on upgrade; (5) stored survey definitions become incompatible with a newer renderer, silently breaking historical response display; (6) missing server-side validation lets malformed or spoofed submissions into the database.
Ramp-up. The package API is small — a couple of models, a controller, one Blade include — so a mid-level Laravel engineer is productive in half a day. The actual cost is learning the SurveyJS JSON schema and expression/validation model, which is where the real complexity lives and where most bugs will originate. Plan one to two days for a technical spike and one to two weeks to productionize a forked, tested, licensed integration with definition versioning and server-side validation.
TPM recommendation. Do not adopt as a hard dependency for a strategic or long-lived feature. Either use it as a one-day reference to seed our own implementation, or fork it under our namespace with pinned assets, tests, and a named owner — contingent on a clean license review. The 13.4 opportunity score and zero dependents tell us the ecosystem has already made this judgment.
How can I help you explore Laravel packages today?