Core Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Composer package for Laravel. Before doing anything else, confirm your app is actually a Symfony app on a 2.8 / 3.x-era kernel — a 2016 bundle with zero tagged releases past December 2016 and no dependents is almost certainly pinned to symfony/symfony ^2.8|^3.0, Doctrine ORM 2.4/2.5, and PHP 5.6/7.0. From a Laravel mindset, the closest mental model is a "shared domain primitives" package you require into several first-party apps, except the wiring is a bundle + DI container instead of a service provider.

Minimal path:

1. composer require grossum/core-bundle — expect this to fail or resolve oddly because there is no stable tag. Plan on "grossum/core-bundle": "dev-master" with an explicit commit hash, and be ready to fork.
2. Register the bundle conventionally in app/AppKernel.php:

   new Grossum\CoreBundle\GrossumCoreBundle(),
   

   Verify the actual class name and namespace from the repo root — do not trust the convention, this bundle predates strict PSR-4 enforcement in many shops.
3. Open DependencyInjection/Configuration.php first. That single file is your entire config contract; the README (if one exists) is unreliable at this age. Every ->scalarNode() / ->arrayNode() there is a key you can set under grossum_core: in config.yml.
4. Second read: Resources/config/services.yml (or services.xml). This tells you what the bundle actually gives you — base entities, repository helpers, paginators, form types, Twig extensions, Doctrine subscribers.
5. First use case: pick the smallest concrete artifact (usually a base entity MappedSuperclass or an abstract CRUD controller) and extend it in one entity or controller. Do not adopt the whole bundle at once.

If you are on Laravel and evaluating this as a port source: don't install it. Read it for its base-entity/paginator/repository abstractions and reimplement them as a Laravel package with a ServiceProvider. Nothing here is Coupling-safe to bring over.

Implementation Patterns

Extend, don't call. Core bundles of this vintage are almost always inheritance-based: abstract entities, abstract controllers, traits for timestamps and blameable fields. Wire it the same way Symfony devs did in 2016 — class Article extends BaseArticle — and keep your own logic in the child so a fork-and-patch of the vendor code stays viable.

Fork-and-vendor is the default pattern. With no maintainer activity since 2016, treat the upstream as a source tree, not a dependency. Commit a fork under your VCS namespace:

"repositories": [{"type": "vcs", "url": "[email protected]:you/core-bundle-fork.git"}],
"require": {"grossum/core-bundle": "dev-master"}

Then patch freely. This is the only sustainable pattern.

Map bundle constructs to Laravel analogues if you're porting concepts:

Integration tips. Register the bundle late in AppKernel so its Doctrine subscribers see a compiled mapping first. If it ships a paginator, keep pagination concerns at the controller boundary — do not let a vendor paginator object leak into your domain layer, because you will replace it. If it ships form types, prefer overriding via form.type_extension tags over editing the bundle.

Workflow. Enable the bundle in a scratch project first, dump the container (debug:container), and inventory every service it registers. That inventory, not the docs, is your adoption checklist — you'll typically find 20% of the services carry 80% of the value.

Gotchas and Tips

• GPL-3.0 is the real decision. For a SaaS you never distribute, it's mostly fine. For anything shipped as a binary, appliance, or on-prem install, GPL-3.0 is viral and will require you to release source. If that's a blocker, the license alone disqualifies the package — decide this before writing code, not after.
• No stable tags since 2016. Composer will happily float you onto a moving dev-master; always pin a commit SHA ("dev-master#abc1234"). This is not optional.
• Symfony version drift. A 2016 bundle frequently uses $container->getDefinition() APIs, ResourceInterface paths, and service ids that changed in Symfony 3.3+/4.0. Expect deprecation floods on 3.4 and hard breaks on 4.x. Run bin/console debug:container --deprecations after wiring.
• Doctrine coupling. Base entities with @ORM\ annotations and MappedSuperclass will fight with newer Doctrine (attribute driver, doctrine/orm 2.10+ deprecating annotations). Mapping inheritance also means schema migrations now depend on vendor code — a vendor field addition becomes your migration.
• Autoload failures are the first symptom. Legacy namespaces (Grossum\CoreBundle\Entity\Base with non-matching directory case) break on case-sensitive filesystems and only on Linux/CI. If it works locally on macOS and fails in CI, look here first.
• Debugging the container. container:debug for services, debug:config grossum_core to see the resolved tree, debug:event-dispatcher to catch subscribers the bundle registered silently. Silent subscribers (e.g. soft-delete filters, blameable listeners) cause "why did this row change?" mysteries — check doctrine.event_subscriber tags before blaming your own code.
• Extension points to prefer over edits: form.type_extension, kernel.event_listener, doctrine.event_subscriber, and compiler passes in your own bundle. Anything you override by editing vendor files will be lost on the next composer update.
• Testing. If the bundle ships its own tests, they're a spec for behavior — read them when docs are missing. If it ships none (likely at this score), write characterization tests around the two or three services you actually use before touching anything.
• Abandonment risk. No releases in ~9 years and zero dependents means no upstream bugfixes, no PHP 8.2+ compatibility work, and no security review. Budget for ownership. If the package is load-bearing, copy the 5–10 files you need into your own src/ and drop the dependency — this is usually cheaper than maintaining the fork.