perform/base-bundle
Perform Base Bundle provides a lightweight foundation for PHP applications and packages, bundling shared base classes, configuration defaults, and service wiring so teams can standardize project structure and reduce repetitive boilerplate.
Confirm what you actually have before installing. The -bundle suffix and the useperform vendor strongly suggest a Symfony bundle, not a Laravel package. Open the repo's composer.json and check:
"type": "symfony-bundle" (vs library)require on symfony/framework-bundle / symfony/dependency-injectionIf it's a Symfony bundle, this is not a composer require-and-go dependency for a Laravel app — it's a small integration project. Decide that up front.
Minimal steps (Symfony path):
composer require perform/base-bundle — pin an exact version (see Gotchas).config/bundles.php if Flex doesn't auto-register it.DependencyInjection/Configuration.php to see what's configurable, then create config/packages/perform_base.yaml.bin/console debug:container perform_ and bin/console lint:container to confirm wiring.Read in this order: README → DependencyInjection/ → Resources/config/services.xml. That triangle tells you what gets registered, what's configurable, and what base classes you're meant to extend.
First use case: wire up one console command or one read-only route that touches the bundle's core services. Prove the container wiring end-to-end before building anything on top — with a 1-star package, wiring is the highest-risk step.
Treat it as a foundation, not a library. A "base bundle" earns its keep by giving you abstract classes and pre-wired services you extend. Inventory the public API (services.xml, interfaces, abstract classes) and write a thin internal adapter so your app code depends on your interfaces, not the bundle's. This is the single most valuable habit with a low-signal dependency.
Config-first. Express behavior through the bundle's YAML rather than subclassing its config classes. Extension config is the most stable surface; internal classes are not.
Decorate, don't fork. Use Symfony service decoration (decorates: / !decorated) to override base services. If the bundle exposes tagged services or compiler passes, register yours via tags — that's the intended composability path.
Laravel bridge, if you must. Isolate everything in one service provider plus one config file:
mergeConfigFrom() for the bundle's defaultsKeep the bridge in a single namespace so removal is a one-line composer change.
Upgrade workflow. Pin "perform/base-bundle": "x.y.*" in composer.json, commit the lockfile, and do version bumps on a dedicated branch with your own smoke test — there's no upstream test signal to rely on.
vendor:publish. If the team is Laravel-only, budget the bridge or reject the dependency — don't hand-wave this.Configuration::getConfigTreeBuilder() for ->defaultValue() vs ->cannotBeEmpty(). Silent no-ops (service present but inert) are the classic failure mode.debug:container perform_, debug:config perform_base, and lint:container will catch ~90% of wiring problems. On the Laravel side, artisan about tells you nothing — dump the container directly.Perform\BaseBundle\...). If you extend into their namespace, a future patch release can collide with your files.How can I help you explore Laravel packages today?