Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Symfony Json Form Laravel Package

precision-soft/symfony-json-form

A Symfony package for working with JSON-driven forms, helping you define, validate, and process form data from JSON schemas within Symfony applications. It integrates with Symfony’s Form component and offers a lightweight way to handle JSON form configurations.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit. This package sits at the boundary between Laravel form handling and a React frontend: AbstractFormService owns request handling and rendering, DTOs are hydrated through Symfony Serializer, and the shipped React assets render the same JSON contract under formV1 and formV2. That is a reasonable fit for Laravel applications with non-trivial form workflows and a TypeScript/React UI. The v1.3.0 addition of hasJsonBody() and constructDto() turns two previously hard-coded decisions into overridable extension points, which improves fit for teams that need custom request-body detection or container-aware DTO construction without forking the package.

Integration feasibility. The package is Composer-installable, and the new .example/ application is export-ignored, so it will not ship in distribution archives. That gives evaluators a runnable reference without adding runtime weight. The React source change (import type plus verbatimModuleSyntax) is directionally correct for modern TypeScript toolchains and should reduce failures in hosts that enforce type-only imports. The JSON-body serializer fix is the most operationally relevant change: JavaScript clients routinely serialize 150.0 as 150, and the prior behavior caused float properties to be rejected as int. That is a real integration defect for any API receiving numeric form data from a browser.

Technical risk. The release fixes a regression introduced in v1.2.0: subclassed DTOs were rejected because the guard compared class names instead of using instanceof. Restoring v1.1.0 behavior is good, but the regression itself is a signal about minor-version compatibility discipline. Two other changes need scrutiny. First, render() now wraps an unbuildable DTO’s ArgumentCountError in the package’s own Exception; that improves diagnosability but changes the exception type host exception handlers may catch. Second, adding overridable methods to AbstractFormService can collide with methods that downstream subclasses already define with the same names, producing fatal errors at class-load time. The serializer format change is scoped to JSON bodies, but it can still alter denormalization behavior for edge-case payloads such as numeric strings. The test-suite move to precision-soft/symfony-phpunit and phpstan/phpstan-mockery is dev-only, but it increases coupling to a less common test harness.

Key questions.

  • What Laravel, PHP, Symfony Serializer, React, and TypeScript versions are supported and tested in CI?
  • Does hasJsonBody() rely only on Content-Type, and does it handle application/json; charset=utf-8 and vendor +json media types correctly?
  • Is constructDto() intended to resolve through the Laravel container, and what is the extension contract for overriding it?
  • Are the new AbstractFormService method names covered by a backward-compatibility policy, and were downstream subclasses checked for name collisions?
  • What is the migration guidance for consumers on v1.2.0 who worked around the DTO subclass rejection?
  • Is the formV1/formV2 JSON schema versioned independently of the PHP package, and what guarantees exist for frontend/backend version skew?

Integration Approach

Stack fit. The package assumes a Laravel backend, Symfony Serializer for DTO hydration, and a React/TypeScript frontend capable of consuming the packaged form JSON. The React source change requires a TypeScript version that understands verbatimModuleSyntax for the package’s own typecheck, but host applications are mainly affected through how they bundle the package sources. Teams on older bundlers or older TypeScript should verify source imports rather than assuming the change is transparent.

Migration path. Consumers on v1.1.0 should upgrade to v1.3.0 to obtain the JSON float fix and the improved DTO-construction error reporting; behavior should remain close to v1.1.0 because subclass DTOs are accepted again. Consumers on v1.2.0 should remove any workaround that avoided subclassed DTOs, then re-run tests around form population and rendering. Any host code catching ArgumentCountError from render() must be updated to catch the package Exception and inspect formName and dtoClass context. Teams that subclass AbstractFormService should check for existing hasJsonBody() or constructDto() methods before upgrading.

Compatibility. The critical compatibility surfaces are the Symfony Serializer version, Laravel version, PHP version, React version, and TypeScript configuration. The JSON-body fix changes serializer invocation for JSON requests only; GET and form-encoded requests remain unchanged. That scope is sensible, but it still warrants regression tests for float fields, integer fields, numeric strings, and nullable numerics. The restored instanceof guard means subclassed DTOs pass again, while unrelated DTO classes should still raise the documented exception with unchanged context.

Sequencing.

  1. Inventory forms with float/numeric fields, subclassed DTOs, custom AbstractFormService subclasses, and custom exception handling around render().
  2. Add integration tests for JSON POSTs where a whole number is sent for a float property, plus tests for GET and form-encoded inputs.
  3. Verify subclassed DTO population and rendering against the new instanceof guards.
  4. Confirm host exception mapping for the package Exception emitted by unbuildable DTOs.
  5. Check frontend build compatibility with import type and any extended TypeScript config.
  6. Deploy the backend package first because the serializer and DTO fixes are server-side; then validate the React renderer against the same JSON payloads.

Operational Impact

Maintenance. The package is actively maintained, but the v1.2.0 regression and its v1.3.0 repair indicate that minor releases can carry behavioral risk. The test suite’s migration to precision-soft/symfony-phpunit is a maintainer-side change; it does not affect runtime, but it may affect contribution workflows and the ability of downstream teams to reproduce package tests. The .example/ app is useful for support and onboarding but is not installed by Composer, so support engineers must reference the repository rather than the installed vendor tree.

Support. Error context is improved: unbuildable DTOs now surface formName and dtoClass with the constructor error as previous, which should shorten diagnosis. The JSON float fix removes a confusing validation symptom that would otherwise generate frontend/backend blame-shifting. Support should publish explicit upgrade notes for v1.2.0 consumers, especially around removed workarounds, changed exception types, and subclassed DTO behavior.

Scaling. The serializer fix is important at scale because browser-originated numeric payloads are pervasive; without it, whole-number floats fail unpredictably depending on client serialization. The new overridable methods allow platform teams to standardize request-body detection and DTO construction centrally, but if every team overrides them differently, form behavior will fragment. The React import type change reduces bundler coupling and should make the frontend half easier to consume across multiple host applications.

Failure modes. A misclassified JSON body can cause serializer format mismatches and validation failures. An unbuildable DTO now raises the package Exception; if the host does not map it, users see a 500 instead of a targeted form error. Adding methods to AbstractFormService can fatally collide with downstream subclass methods. The restored subclass acceptance could change behavior for anyone who relied on v1.2.0’s rejection, though that is unlikely and was itself a regression. Example CI gating can fail on dependency drift in .example/, but that does not affect installed consumers.

Ramp-up. Developers need to understand the form-service/DTO/React-schema triad. The runnable .example/ product editor materially lowers ramp-up because it exercises every element type, context hooks, a value object, and both formV1 and formV2 rendering. A short upgrade spike on one representative form with floats and a subclassed DTO should be sufficient to validate v1.3.0 before broader rollout.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
alphabalex/messaging-made-easy
rawphp/warp
shootkiran/merobug
narakode/fineauth
numencode/wn-syncops-plugin
ibnnajjaar/mib-global-pay
ably/pubsub-server
mstfkhazaal/defender
mfonte/base62x
karnoweb/metapilot
tobya/bcsapiwrapper
swalker2/cpanel
vish4395/laravel-translation-manager
morningtrain/economic
teksite/systeminfo-laravel
atomcms/voting
run6/weather
siokas/laravelembeddirectives
adamlien/pkuuids
gilsonsouza/lara-doc-generator