idmarinas/common-bundle
idmarinas/common-bundle is a shared PHP package that gathers reusable utilities, helpers, and conventions for Laravel and other PHP applications. It aims to reduce duplication and standardize common setup, giving projects a lightweight foundation for consistent, maintainable code.
This is a Symfony bundle, not a Laravel package — there is no ServiceProvider, no publishable config, no config/common.php. So the first thing to settle is whether you actually have a Symfony app that needs it. If your day-to-day is php artisan, the "Getting Started" is really "understand what it does, borrow the pieces you like, and move on" (see Gotchas).
As of 3.6.0 there is finally real documentation: https://idmarinas.github.io/common-bundle/index_topic.html. Start there before the source — it's the first release where "read the docs" beats "read the code." If the docs page 404s or lags the tag, fall back to the source-reading order below.
For a Symfony codebase, the minimal day-one steps:
composer require idmarinas/common-bundleconfig/bundles.php:
Idmarinas\CommonBundle\CommonBundle::class => ['all' => true],
bin/console debug:container --tag=twig.extension and debug:config against whatever alias the bundle's extension exposes.composer.json for the pinned symfony/* constraints. Because adoption is tiny, the bundle is likely maintained against one Symfony major line; confirm it matches your app before installing.Where to look first (in order):
README.md — still sparse; treat it as a pointer to the docs, not documentation itself.DependencyInjection/ — the extension class is the source of truth for config keys and service wiring.Resources/config/services.php (or .yaml) — the actual list of services you inherit.Tests/ — if present, the fastest "documentation" of intended usage and edge cases.First use case: scaffolding a new Symfony app and skipping the boilerplate you'd normally copy-paste between projects — base controller methods, entity traits (timestamps/slug/soft-delete style), Twig helpers, maybe a utility service or two. In Laravel terms: it is the Symfony equivalent of a "starter kit" of base classes and helpers, not a feature package.
Extend, don't copy. The bundle's value is concentrated in abstract classes and traits. If it ships an AbstractController or an entity trait, use the trait in your Doctrine entity or extends the controller — you inherit upstream fixes and keep your own class thin. The 3.6.0 docs enumerate the available abstractions; skim that list before writing your own base classes.
// Example shape — confirm exact namespace from the repo/docs
use Idmarinas\CommonBundle\Model\TimestampableTrait;
class Article
{
use TimestampableTrait;
}
Configure via the package namespace. Symfony bundles get a config section named after the extension's alias (commonly idmarinas_common or similar). Put overrides in config/packages/<alias>.yaml, and verify with:
bin/console debug:config <alias>
Autowiring is your friend here. With Symfony's default services.yaml (_defaults: autowire: true, autoconfigure: true), any concrete service the bundle exposes will inject itself into your constructors for free. If a service isn't autowirable, you'll see it in debug:container — then either alias it or fetch it explicitly.
Integration tip — layer it at the "base layer" of your app. Use traits and abstract classes in your App\Entity and App\Controller base classes so every concrete class inherits the behavior. Don't scatter direct calls to bundle utility services across controllers; wrap them in one domain service so you can swap the bundle out later without a grep-and-replace.
Workflow fit: it's most useful at greenfield time (new app scaffold, new bounded context) and least useful when retrofitting a mature app — the bundle won't wire itself into existing conventions, and rewriting mature base classes is rarely worth it for what are usually small helpers.
If you're on Laravel anyway: mirror the patterns instead of installing the package. The pieces this bundle tends to cover map cleanly onto Laravel idioms — base model traits → model traits; Twig extensions → Blade directives; abstract controllers → App\Http\Controllers\Controller; utility services → app/Support. Port 20–50 lines rather than introducing a Symfony runtime dependency into a Laravel app.
This is not a Laravel package. No Illuminate\Support\ServiceProvider, no php artisan vendor:publish, no facades. Any attempt to composer require it inside a Laravel app will either fail on the symfony/framework-bundle dependency or install dead code. The realistic play for a Laravel shop is to read it as reference material, not to depend on it.
Adoption is effectively zero (2 stars, 0 dependents). That's not disqualifying — plenty of useful internal bundles look like this — but it means: no community answers, no Stack Overflow safety net, and you are the maintainer of your integration. The new docs site in 3.6.0 softens this considerably (official prose beats reverse-engineering), but it does not create a support network. Pin the exact version in composer.json ("idmarinas/common-bundle": "x.y.*") and vendor-fork if you depend on it in production. Treat a fork as the default plan, not the contingency.
Version pinning is the real risk. Check the bundle's composer.json require block against your app's Symfony version before installing. Because the release cadence is sparse, a Symfony minor bump can leave you stranded with an incompatible bundle and no upstream fix coming soon.
Docs-vs-tag drift is the new gotcha. 3.6.0 ships docs alongside the code, but a docs site is usually built from main and may describe APIs not yet in your pinned tag, or omit ones you have. Treat the docs as a map and debug:container as the territory. If a docs snippet references a class that doesn't exist in your installed version, that's normal lag, not a broken install.
Debugging workflow when something "isn't working":
bin/console debug:container <service-id> — is the service even registered?bin/console debug:config <alias> — did your YAML load under the right key?bin/console debug:router — if it ships routes, are they actually imported (Symfony bundles don't auto-import routes; you must add them in config/routes.yaml)?config/bundles.php registration order — misordering matters when bundles decorate the same service.Extension points and clean exit strategy. Before adopting, identify what you'd need to reimplement to drop the bundle: traits are trivial to inline, abstract controllers are one-file copies, Twig extensions are small classes. If the "exit cost" is under an hour, adopt freely. If it's a week of untangling, don't — it's not a dependency you want to be stuck with given the maintenance signals.
Release note minimalism is a pattern, not a one-off. 3.6.0's entire "changelog" is a docs link plus a compare URL — no breaking-change callout, no BC note. Assume every minor bump could touch public API until you diff it. Before upgrading from 3.5.1 to 3.6.0, read the compare link (.../compare/3.5.1...3.6.0) for actual file changes rather than trusting the release body; a "minor" by semver is a promise the author may not have audited if there's no CI enforcing it.
License is friendly. BSD-3-Clause permits commercial use, modification, and redistribution; just keep the copyright notice and don't use the author's name to endorse your product. Forking under BSD-3 is legally straightforward — which reinforces the "vendor-fork rather than rely on upstream" recommendation above.
How can I help you explore Laravel packages today?