Ember Data Serializer Bundle Laravel Package

Getting Started

This release is a compatibility bump, not a feature drop: version 1.1.0 adds Symfony 3.0 support, which in practice means the package's composer.json constraint on the Symfony components it touches has widened to something like ~2.7|~3.0. Nothing in your day-to-day API changes — the value is that you can now install the package alongside a Laravel version that has moved off Symfony 2.7/2.8 components.

Minimal path to first use:

1. Confirm your framework baseline before anything else. Check composer show symfony/console symfony/http-foundation (and whichever other components the package pulls in). If you are on a Laravel release pinned to Symfony 2.7/2.8, this release is a no-op for you — you are on the 2.x code path and should still take the upgrade for future-proofing, but expect no behavioural difference.
2. Update with a constraint bump, not a blind composer update: composer require vendor/package:^1.1 --update-with-dependencies. Widening a Symfony constraint frequently forces Composer to re-resolve the whole component graph; --update-with-dependencies keeps that resolution local rather than upgrading half your lockfile.
3. Where to look first: the package's service provider. It is the single file that tells you how much surface area the package actually exposes — bindings, singletons, config publishing, command registration. Read it before reading any other class; it tells you which Symfony component is really load-bearing.
4. First meaningful use case: whatever the package wraps (a console command, a request transformer, a dispatcher subscriber), run it once under your current Laravel version and once after the bump. The Symfony 3.0 removals are almost always runtime-only failures on rarely-executed branches, so a happy-path smoke test is not sufficient — see the Gotchas section.

Implementation Patterns

Pin the constraint to match your framework, not to match the package's maximum. Because 1.1.0 supports both Symfony 2.7 and 3.0, the package constraint is permissive but your application constraint is what actually selects the code path. Two patterns:

// Laravel pinned to Symfony 2.7/2.8 — 2.x code path
"vendor/package": "^1.1",
"symfony/console": "~2.8"

// Laravel on Symfony 3.x components — 3.x code path
"vendor/package": "^1.1",
"symfony/console": "^3.0"

Never let the package's transitive Symfony constraint be the thing that decides which major component version your app loads. Declare it explicitly at the root.

Isolate the package behind your own binding. Since the dual-support window means two code paths coexist in the same dependency tree, anything that touches Symfony component classes directly should sit behind a small application-level interface with a container binding. That way, if the package later drops 2.x (or you need to switch), you change one binding rather than every call site:

// config/app.php providers
Vendor\Package\PackageServiceProvider::class,

// a thin adapter you own
$this->app->singleton(MyApp\Contracts\Thing::class, MyApp\Adapters\PackageThing::class);

Register and consume via the container, never new. Symfony 3.0 tightened several constructor signatures and removed helper classes; instantiating package classes directly means you inherit those signatures as hard coupling. Resolve from the container so constructor changes are absorbed by the provider.

If the package ships Artisan commands, they are the highest-risk surface for this release (see Gotchas). Register them in the provider and verify them in tests with $this->artisan('package:command') rather than shelling out — the assertion catches the return-code strictness change described below.

Test matrix tip: if you maintain anything downstream of this package, run CI against both Symfony 2.8 and 3.x component sets now, while 1.1.0 supports both. The 2.x lane is effectively a dead branch; anything you find only failing there can be triaged as "ignore" rather than debugged.

Gotchas and Tips

The release note tells you less than you need. "Symfony 3.0 Support" on issue #4 means "we removed the code that 3.0 deleted." The failure mode is not a fatal error on install — it is a Class not found, a signature mismatch, or a silently different return value on a code path your tests do not cover. Treat the whole package as unverified until you have exercised it.

The specific Symfony 3.0 removals most likely to bite a Laravel package:

• DialogHelper and ProgressHelper were removed. If any package command still references them, you get a class-not-found at command execution time, not at boot. Grep the vendor tree: grep -rn "DialogHelper\|ProgressHelper" vendor/vendor/package/.
• Form/Validator setDefaultOptions() was removed in favour of configureOptions(). Any package type class extending a Symfony form type or constraint will fatal on first use.
• Command::run() return-value strictness. In 3.0 the integer return propagates strictly; commands that return null or a non-int from execute() now surface as console errors or unexpected exit codes. This is the single most common "works on 2.x, broken on 3.x" symptom for Laravel packages.
• Request::get() / parameter-bag behaviours and SessionInterface method availability changed around this generation; if the package manipulates the request object, check that it does not rely on removed convenience accessors.

Composer traps. A widened constraint can produce a lockfile where symfony/* components are on mixed major versions if some other dependency still pins 2.7. composer why symfony/console is the fastest diagnostic. Also: after upgrading, run composer dump-autoload -o — removed-class references resolve at autoload time in a way that can mask themselves under a warm non-optimised autoloader.

Debugging strategy. When something misbehaves after the bump, do not start at your application code. Start with php artisan --version, then composer show | grep symfony, then reproduce the failure inside a single php artisan tinker line. That sequence establishes which Symfony major you are actually running — the overwhelmingly common cause of "the upgrade broke it" is that you are not running what you think you are.

Extension points are the safe bet. If you need behaviour the package does not offer, prefer overriding via the published config and container bindings over subclassing its classes. Subclasses inherit constructor and method signatures that are exactly what is changing between Symfony majors — binding and composition will survive the next bump, subclassing will not.

Deprecations to expect next. The Symfony 2.7 branch that 1.1.0 still supports is EOL. Assume a future 2.0.0 drops it, and treat any current dependence on the 2.x code path as technical debt with an expiry date. Now — while both paths work — is the cheapest moment to verify you are genuinely running the Symfony 3 path in production.