- Can I use mtarld/json-encoder-bundle in Laravel?
- Not natively. mtarld/json-encoder-bundle is a Symfony bundle that depends on Symfony bundle registration, kernel compiler passes, and container compilation, none of which exist in Laravel. The practical route is to require the underlying mtarld/json-encoder package as a dev dependency and hand-wire generation as a build step. That integration is undocumented and would be your team's responsibility.
- How do I install and configure mtarld/json-encoder-bundle?
- In Symfony you install it with Composer, register the bundle in bundles.php, and configure encoding options such as bitmask and depth under the bundle config. It registers the JSON encoder as a service with autowiring, so you inject SerializerInterface and encode without boilerplate. In Laravel there is no bundle registration or config file, so these steps do not apply.
- Does this bundle replace Symfony Serializer or JMS Serializer?
- No. It integrates a JSON encoder with the Symfony Serializer and works transparently through SerializerInterface rather than replacing it. It generates encoders and decoders from PHP class attributes to avoid runtime reflection costs. You still use the serializer for normalization and denormalization.
- What Laravel and PHP versions are supported?
- There is no Laravel version support because the package is Symfony-only. The repository was archived in March 2024, and its pinned Symfony and parser dependency ranges are likely to conflict with current Symfony 7.x and Laravel 11.x releases. The standalone generator may work on PHP 8.1 through 8.3, but newer PHP versions are unverified.
- Is mtarld/json-encoder-bundle maintained and safe for production?
- Treat it as high risk. The repository is archived, has roughly 10 stars, zero dependents, and a bus factor of one, so there are no security patches, no PHP 8.4 or 8.5 guarantees, and no fixes for breaking transitive dependencies such as nikic/php-parser. For production you would need an owner for a fork and a review cadence for compatibility.
- How does the compile-time encoder generation work and does it fit Laravel?
- The bundle uses a DI compiler pass to walk the codebase and emit encoder classes based on PHP attributes, which removes runtime reflection cost. Laravel has no equivalent container compilation phase, so you would invoke the generator through a Composer script or artisan command in CI. The generated code is a build artifact that must be regenerated deterministically and kept in sync with model changes, and drift is a silent failure mode.
- What are alternatives to this bundle for Laravel JSON serialization?
- For Laravel, evaluate Illuminate Http Resources, spatie/laravel-data, hand-written hydrators, or a Symfony Serializer bridge first. Those options are maintained and staffed by people other than you, unlike this archived bundle. Benchmark against API Resources; if serialization is not materially too slow, this dependency buys nothing.
- How should I test generated encoders and decoders in a Laravel app?
- Start with a one-to-two day spike on one representative model, wire generation end-to-end, and benchmark it against Laravel API Resources. Add a CI diff check to prove deterministic generation before writing production code. Also test the generated decode path with untrusted payloads, including type coercion and unknown properties, and get explicit sign-off.
- Does the generated decoder safely handle untrusted request payloads?
- That is not established by the package or its documentation. The evaluation flags type coercion and unknown-property handling as open questions, and there is no Laravel-oriented guidance or community evidence to rely on. You would need to audit the generated decoders yourself and assign a named owner for security sign-off.
- What is the migration path or exit cost if I adopt it?
- If you pursue it, add mtarld/json-encoder as require-dev, generate into a dedicated namespace in CI, and register generated classes in a service provider; do not try to load the bundle itself. If you already use API Resources or Symfony Serializer, this is a parallel serialization path rather than a migration, and doubling that surface should be a hard stop. The exit cost is moderate because generated classes are build artifacts, but you will likely need to migrate when the archived dependency breaks.