Jms Serializer Bridge Laravel Package

Getting Started

Reality check first. This package was last released in June 2018, has zero stars and zero dependents on Packagist. It is a thin integration layer for a niche CMS (Superdesk Web Publisher, a Symfony-based publishing platform) and is almost certainly abandoned. Do not adopt it in a new Laravel project unless you are specifically maintaining an existing SWP installation that already depends on it.

Installation (PHP 7.x + Symfony, not Laravel). The bridge is a Symfony Bundle, so it will not run in a stock Laravel app without pulling in a Symfony kernel, the JMS Serializer Bundle, and SWP's own core packages. In a genuine SWP codebase:

composer require swp/jms-serializer-bridge

Then register the bundle in app/AppKernel.php (Symfony 3/4 era) or config/bundles.php:

// config/bundles.php
return [
    // ...
    SWP\Bundle\JmsSerializerBridgeBundle\SWPJmsSerializerBridgeBundle::class => ['all' => true],
    JMS\SerializerBundle\JMSSerializerBundle::class => ['all' => true],
];

Where to look first. Inspect the DependencyInjection/ and Serializer/ (or Handler/) directories in vendor/swp/jms-serializer-bridge/. Since the repo ships no documented API, the actual service definitions and tagged serializer handlers are the source of truth. Run bin/console debug:container --tag=jms_serializer.subscribing_handler to see which handlers this bridge registers.

First use case. Serializing an SWP content entity (Article, Tenant, Package) to JSON for the content API. In practice the bridge just ensures SWP's domain objects are correctly wired into JMS Serializer's metadata and handler pipeline — you call the serializer exactly as you would in any JMS Serializer project:

$json = $this->get('jms_serializer')->serialize($article, 'json', SerializationContext::create()->setGroups(['api']));

Implementation Patterns

Content API serialization. The most common pattern is exposing an SWP entity through a REST endpoint using FOSRestBundle + JMS Serializer, with the bridge supplying any SWP-specific type handlers or metadata loaders. Controllers typically look like:

public function showAction(Article $article)
{
    $context = SerializationContext::create()
        ->setGroups(['api', 'article_details'])
        ->setSerializeNull(true);

    return new Response(
        $this->serializer->serialize($article, 'json', $context),
        200,
        ['Content-Type' => 'application/json']
    );
}

Define the groups via annotations on the SWP entity (or via YAML mapping in Resources/config/serializer/) and let the bridge handle the SWP-specific plumbing.

Context-driven versioning. A common workflow is to use JMS SerializationContext versions (->setVersion('1.0')) to expose different fields for different API clients. The bridge's handlers should respect these contexts automatically if they follow JMS conventions — verify by serializing with two versions and diffing the payload.

Custom handler registration. If SWP adds domain types that JMS Serializer doesn't understand, register a handler/service tagged jms_serializer.subscribing_handler in your app's services.yaml:

services:
    App\Serializer\CustomSwhHandler:
        tags:
            - { name: jms_serializer.subscribing_handler }

This is the main extension point the bridge leaves open — you don't modify the bridge itself, you extend JMS Serializer and let the bridge's wiring pass your handler through.

Fixture/dump workflows. When debugging, use the JMS Serializer CLI (if you have jms/serializer-bundle CLI commands enabled) or a small script that calls serialize() with setSerializeNull(true) and various groups to see exactly which fields the bridge is including vs. dropping.

Gotchas and Tips

• PHP version lock-in. A 2018 release targets PHP 7.1/7.2 and JMS Serializer ~1.x. Running it on PHP 8+ will almost certainly fail on return type declarations or deprecated SerializationContext APIs. Test the install in a throwaway environment before touching production.
• No maintenance = no security patches. Treat this as frozen. Fork it into app/ and vendor it locally if you must keep it, so you control upgrades.
• Symfony, not Laravel. There is no Laravel service provider, no config publish, no Artisan command. If your project is Laravel, you are effectively porting the bridge yourself — probably better to depend directly on jms/serializer and register handlers manually in AppServiceProvider.
• Debugging serialization output. The most common failure mode is silent field omission. Turn on setSerializeNull(true), and add a __debugInfo() or use dump() on the entity before serializing to confirm the properties exist. Check the JMS metadata cache (var/cache/*/jms_serializer) — stale metadata after entity changes is a frequent red herring; clear cache aggressively.
• Cache warmup ordering. If the bridge registers metadata dirs, they are loaded during container compilation. Adding new mapping YAMLs without clearing the Symfony cache is the #1 "it works on my machine" bug.
• Version constraints will bite. swp/jms-serializer-bridge pins JMS Serializer to an old minor range. If your SWP upgrade pulls JMS Serializer 3.x, Composer will conflict. Use composer why-not swp/jms-serializer-bridge to see the exact constraint before planning an upgrade.
• Zero signal for adoption risk. With no dependents and no recent commits, you have no community to ask for help. Budget for reading the source (it's small) and taking ownership of the code if it breaks.
• Extension point is JMS, not the bridge. Almost every customization you'd want (groups, versions, handlers, metadata) belongs to JMS Serializer, not this package. Keep your changes in app-level services tagged jms_serializer.subscribing_handler so a future removal of the bridge is a one-line change.