Rest Base Bundle Laravel Package

Getting Started

First, the framing: visual-craft/rest-base-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no config/rest-base.php, and no php artisan vendor:publish. Day-to-day, you'll only touch it if you're working in a Symfony service (or a legacy app where Symfony components are pulled in). From a Laravel codebase, the realistic uses are: (a) you inherit a Symfony REST API and need to orient fast, or (b) you're mining it for patterns to port into a Laravel API base layer.

Install and confirm compatibility:

composer require visual-craft/rest-base-bundle:^0.6.0

v0.6.0 is a compatibility-only release — the sole change is Symfony 8 support (PR #25). There are no new features, no deprecations, and no API changes. Treat the upgrade as a constraint-widening exercise, not a feature adoption.

Where to look first (in order):

1. composer.json — confirm symfony/* constraints and the minimum PHP version. Symfony 8 requires PHP 8.4+, so a Symfony 8 install implicitly raises your floor even though the bundle itself did not.
2. Resources/config/ (or config/) — the bundle's service definitions; this tells you what's auto-wired and what you can override.
3. DependencyInjection/ — the extension class and any configuration tree, i.e. the actual knobs you have.
4. The README and a couple of src/ classes — at v0.x the API surface is still settling, so read the code rather than assuming docs are current.

First use case: register the bundle in config/bundles.php (Symfony) and confirm the container compiles cleanly on your target Symfony version before writing any application code. A bin/console cache:clear that compiles without deprecation notices is your green light.

Implementation Patterns

Pin the major, float the patch. At 0.x, minor bumps may carry behaviour changes even when this one didn't:

"visual-craft/rest-base-bundle": "^0.6"

Version-matrix your CI. Since v0.6.0's entire value is Symfony 8 support, add a job that resolves against both your current Symfony line and 8.*. That's the only way to catch a future regression in the compat path:

strategy:
  matrix:
    symfony: ["^7.0", "^8.0"]

Upgrade sequencing when moving to Symfony 8. The bundle is one node in the graph — resolve the whole set at once:

composer why-not symfony/framework-bundle 8.*   # find the blockers
composer update "symfony/*" visual-craft/* --with-all-dependencies

If a sibling Visual-Craft bundle (or any third-party bundle you rely on) hasn't shipped Symfony 8 support, --with-all-dependencies will surface it immediately rather than at runtime.

Isolate the bundle behind your own base layer. Given the 0.x version and single-maintainer cadence, don't let controllers extend the bundle's base classes directly. Wrap it:

// App\Api\BaseController — your seam
abstract class BaseController extends \VisualCraft\RestBaseBundle\...\AbstractController
{
    // override here once, not in 40 controllers
}

When the bundle changes, you patch one file.

Cross-pollinating into Laravel. If you're reading this bundle for ideas, the transferable pieces are the REST response envelope (consistent error shape, status-code mapping) and request/response lifecycle hooks — both map cleanly onto Laravel middleware and Responsable/JsonResource. The Symfony-specific DI and event-dispatcher wiring does not port; don't try to carry it across.

Gotchas and Tips

PHP 8.4 is the real gate, not Symfony 8. The release note says "Symfony 8 support," which is a composer.json constraint change. But installing Symfony 8 forces PHP ≥ 8.4. On PHP 8.1–8.3 you can upgrade to ^0.6.0 and stay on Symfony 6.4/7.x with zero behaviour change — and that's the low-risk move.

v0.6.0 is not a breaking change. If you're already on ^0.5, the upgrade is safe; the constraint widening is additive. Don't schedule a migration window for it.

Symfony 8 support ≠ Symfony 8 tested. "Add support" typically means the constraint and CI matrix were updated for one PR. Verify against your own integration tests, especially the container-compile step and any deprecation-triggered failures (SYMFONY_DEPRECATIONS_HELPER=max[self]=0 in CI will make these loud).

Watch transitive constraints, not just this bundle. The most common failure mode here is not this package — it's a doctrine bundle or serializer adapter stuck on Symfony 7. The composer why-not command above is your first diagnostic.

0.x means no BC promise. Semantic versioning guarantees don't apply below 1.0. Pin exactly (0.6.0) if you need reproducibility for a release, and read the diff between minors — the changelog here is a single line, which is honest but tells you nothing about internals.

Bus-factor risk. One PR, one contributor, and a terse changelog. Before deep investment, check release cadence and open-issue response times. For anything load-bearing, keep your BaseController seam (above) so you can fork or replace without a rewrite.

Debugging tip: when something looks like a bundle bug, first confirm the bundle is actually loading — bin/console debug:container --tag=kernel.event_subscriber and debug:config will tell you whether its services registered or whether you're chasing a config-tree error that silently no-op'd.

Extension point to prefer: service decoration (decorates: in services.yaml) over subclassing. It survives upstream refactors far better than inheritance, which matters at 0.x.