Parameter Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — despite the framing. It ships as smartbooster/parameter-bundle with a bundle class, Doctrine entity, Sonata admin, and a console command. If you're in a Laravel codebase, stop here: there is no service provider, no facade, no publishable config, and no config/parameter.php. It will only work inside a Symfony application (or a very deliberate, painful bridge).

For a Symfony app:

1. composer require smartbooster/parameter-bundle
2. Register SmartBooster\ParameterBundle\ParameterBundle in config/bundles.php
3. Add a minimal config file (e.g. config/packages/parameter.yaml) — v1.0.0 adds "bundle Configuration", so a smart_booster_parameter: (verify the exact root key in the bundle's DependencyInjection/Configuration.php) root with at least an entity class or source path is likely required
4. Generate and run a Doctrine migration for the Parameter entity — the mapping format (annotation/XML/attribute) is not documented in the release notes, so read Entity/Parameter.php first
5. Run the load command (bin/console + tab-complete, or debug:console | grep -i parameter) to seed rows from your source config
6. Confirm the admin shows up in Sonata

Where to look first: DependencyInjection/Configuration.php (what's actually configurable), Entity/Parameter.php (the schema you'll migrate and query), then ParameterProvider (your read API) and ParameterLoader + its command (your write path).

First real use case: moving operational settings — feature flags, rate limits, contact emails, threshold values — out of YAML and into the database so non-developers can edit them through Sonata without a deploy. The provider is the intended read path; the loader is how you bootstrap and version-control the defaults.

Implementation Patterns

Read through the provider, never the repository. Inject ParameterProvider into services and controllers and treat it as your settings API. Going straight to the Doctrine repository couples your code to this bundle's schema and makes swapping the implementation later a refactor instead of a rebind. Because v1.0.0 exposes a very small surface, wrap it in your own SettingsInterface from day one and have one adapter class delegate to the provider.

Seed via the loader command, in the deploy pipeline. Keep a canonical parameter definition file in the repo (the source format the loader reads — check ParameterLoader for whether it wants YAML, a directory of files, or an array), and run the load command as a deploy step. This gives you reviewable, versioned defaults and a single source of truth, with the DB as the runtime store.

Separate "defaults" from "admin overrides." The natural pattern is: loader writes defaults, admins edit rows, your app reads the merged result. If the loader overwrites unconditionally, restrict it to insert-if-missing in a small custom service rather than running the stock command on every deploy.

Environment-scoped parameters. If the entity carries a scope/environment column, resolve the provider per-environment at request time (request listener or a scoped service binding) rather than trying to keep one global provider accurate across dev/staging/prod.

Cache aggressively behind an invalidation hook. Parameter lookups will be hot. Put a PSR-6/PSR-16 cache in front of the provider and clear it in a Doctrine postPersist/postUpdate/postRemove listener on the Parameter entity, plus after the load command runs. This is also the pattern that makes the bundle's own lack of caching a non-issue.

Sonata admin as the editing surface only. Don't let admin editing become your integration point — no business logic in admin classes, and treat the admin as replaceable with a bespoke CRUD form if Sonata's footprint is unwanted.

Migration shim for the admin, not the settings. If Sonata isn't already in the project, consider installing only the bundle's provider/loader/entity and skipping the admin service registration, so you're not dragging in the full Sonata stack.

Gotchas and Tips

Framework mismatch is the headline. Everything about this release — bundles, Sonata, Doctrine entities, a console command — is Symfony. Laravel developers should not adopt this; use spatie/laravel-settings or a simple key/value model instead. If you need shared behavior across both frameworks, keep the parameter concept at the HTTP/API layer.

v1.0.0 is a first release with a tiny commit history. Issue #2 covers config, entity, provider, loader, command, and admin all at once. Expect the API to move. Pin an exact version ("smartbooster/parameter-bundle": "1.0.0"), not a caret range, and re-read the diff on every bump.

Entity mapping and migrations will bite first. The bundle's entity mapping format determines whether doctrine:migrations:diff picks it up. If the mapping is XML or annotations while your app is attribute-only, or if the bundle expects the entity to live in your src/Entity, you'll get "table not found" at runtime with no obvious cause. Run doctrine:mapping:info early and confirm the Parameter entity is listed as mapped.

Loader command re-runnable = data loss risk. The whole point of DB-backed parameters is that admins edit them. If the loader upserts and overwrites, a routine deploy silently reverts production tuning. Test the command twice in a row against a DB with a hand-edited row before wiring it into CI/CD.

Sonata admin is a heavy optional dependency. It pulls sonata-project/admin-bundle, sonata-project/block-bundle, and friends, plus its own config and routes. It also has strict version constraints against Symfony and Doctrine; expect Composer resolution friction. Verify the admin service registration can be disabled via config before committing.

"Configuration" is undocumented in the notes. The release says a Configuration was added but not what keys exist. Read Configuration.php and Extension.php rather than guessing — the root alias may differ from the package name, and a wrong root key is silently ignored in Symfony (no error, just defaults).

Debugging drift between config and DB. When a value looks wrong, check three places in order: the container parameter (if the bundle maps anything through the container), the cache (stale entries survive cache:clear if you're on a shared Redis pool — use a versioned key namespace), and the DB row. The provider may also memoize per-request, so a change made mid-request won't be visible.

No documented extension points yet. Don't subclass the provider or loader. Compose instead: your own interface, one adapter around the provider, one service around the loader, one Doctrine listener for cache invalidation. When the bundle's internals shift in v1.1, only the adapter changes.

Console command naming. The command name isn't stated — assume a smartbooster:parameter:load-style name but confirm with bin/console list rather than hardcoding it in a Makefile or CI config, where a rename silently breaks your deploy.