Core Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/core.php. If you're coming from Laravel, translate the mental model first — bundles are registered in config/bundles.php, configured under config/packages/*.yaml, and wired through the DI container.

Minimal steps:

1. composer require whatwedo/core-bundle — expect no Flex recipe. Small bundles like this rarely ship one, so you will likely register it manually in config/bundles.php:

   return [
       // ...
       whatwedo\CoreBundle\whatwedoCoreBundle::class => ['all' => true],
   ];
   

2. Look at src/DependencyInjection/Configuration.php first. For a "reusable components" bundle, the config tree is the public API. That file tells you every option, default, and what the bundle expects from your app. Read it before the README.
3. Then read src/DependencyInjection/*Extension.php to see which services are registered conditionally and which tags/interfaces it auto-configures.
4. First real use case: do not call this bundle directly in controllers. Its job is to be the shared substrate for the whatwedo family (TableBundle, CrudBundle, UserBundle, etc.). Your first productive use is either (a) extending its abstract base classes for your own entities/services, or (b) installing one of the sibling bundles and letting it pull Core in transitively — that's where the value shows up.

If you're evaluating it standalone, scan src/ for Abstract*, *Trait, and *Interface files. Those are the extension points you'll actually touch; concrete classes are mostly internal plumbing.

Implementation Patterns

Extend the abstracts, don't fork them (at first). The bundle's contract is almost certainly a set of abstract base classes and interfaces intended for subclassing — base entity with ID/timestamps, abstract controllers, base form types. Subclass in src/, override protected methods, and leave vendor/ untouched.

Autoconfiguration via interfaces. Check the bundle extension for registerForAutoconfiguration() calls. If it tags services implementing its interfaces, your job is simply to implement the interface and let Symfony wire it — no manual services.yaml tags. Verify with:

bin/console debug:container --tag=<tag_from_the_extension>

Compose, don't inherit, where traits exist. If Core ships traits (timestampable, blameable, sluggable-style concerns), prefer use over deep inheritance chains — multiple whatwedo bundles may want different combinations, and trait conflicts are easier to resolve than diamond inheritance.

Pin hard. With 6 stars, 0 dependents, and no semver stability guarantee, pin to a commit in composer.json rather than a floating constraint:

"whatwedo/core-bundle": "dev-main#a1b2c3d"

Then upgrade deliberately, one sibling bundle at a time, running your test suite in between.

Treat it as vendored code you own. The realistic integration pattern for a low-traffic bundle is: fork it, or copy the two or three classes you actually use into your own App\Shared\ namespace. If you only need the AbstractEntity and a Twig extension, a fork is cheaper than tracking upstream.

Shared-kernel integration. If you run several whatwedo bundles together, Core is the version bottleneck — all siblings constrain it. Resolve with composer why whatwedo/core-bundle and composer why-not whatwedo/core-bundle <version> before bumping anything, and expect to upgrade the whole family in lockstep.

Config file. Create config/packages/whatwedo_core.yaml early, even if it's just whatwedo_core: ~, so the config tree is validated at compile time rather than at first runtime use.

Gotchas and Tips

• It is not a Laravel package. Reaching for app(), facades, or Eloquent-style active records will fail. Everything is constructor-injected services and Doctrine entities/repositories. If you need a Laravel-side equivalent, you are porting, not installing.
• Zero dependents on Packagist is a signal, not a bug. Real consumers are the whatwedo sibling bundles, which don't declare it publicly in a way Packagist counts. Don't read "0 dependents" as "unused" — but do read it as "no ecosystem pressure to keep BC."
• No Flex recipe → silent misconfiguration. If you forget config/bundles.php, you get confusing "service not found" errors rather than a clear "bundle not registered." Add the bundle and the config stub in the same commit.
• Inter-bundle version conflicts are the most likely failure mode. composer update on a sibling bundle can silently drag Core to an incompatible commit. Use composer why-not and constrain Core explicitly in your root composer.json.
• Watch for deprecations on modern PHP/Symfony. A low-traffic bundle often lags behind Symfony's DI and Doctrine ORM deprecation cycles. Run your test suite with SYMFONY_DEPRECATIONS_HELPER=max[direct]=0 (or weak) early so you learn about them before they become fatal on the next major.
• Debugging checklist: bin/console debug:config whatwedo_core for the resolved config tree, debug:container --tag=… for autoconfigured services, lint:container for compile-time DI problems (which is where bundle wiring errors usually surface, not at runtime). If a class is autowired but not found, check the bundle's composer.json PSR-4 mapping against the actual directory layout — small bundles sometimes rename namespaces in refactors.
• Extension points to prefer: interfaces + autoconfiguration tags first, service decoration (decorates:) second, subclassing abstract base classes third. Avoid copying concrete internal services — those are the most likely to change without notice.
• Snapshot your assumptions. Because there's no BC promise, write one integration test that instantiates each Core base class/service you depend on and asserts its shape. That single test is what will tell you, on upgrade day, exactly what broke — in a package where release notes may be thin or absent.