Framework Bundle Laravel Package

Getting Started

Minimal adoption path for fusonic/framework-bundle:

1. Confirm the package is installable and maintained: check the Packagist entry, the composer.json require block (Symfony and PHP version constraints), and the commit history. With 1 star and 0 dependents, treat it as an internal utility library rather than a community-supported bundle.
2. Install with composer require fusonic/framework-bundle, then register the bundle in config/bundles.php (Fusonic\FrameworkBundle\... — confirm the exact class from the package's src/ or README).
3. Look first at, in this order:
   • README.md (short, likely the only docs)
   • src/ directory tree — this bundle is a grab-bag of classes, so the namespace layout is the real documentation
   • DependencyInjection/ (extension + Configuration.php) to see what config keys and services are registered
   • CHANGELOG.md and tagged releases for stability signals
4. Inspect what it actually wires up: php bin/console debug:container --tag=... and php bin/console debug:config fusonic_framework (replace with the real alias from the extension).
5. First use case: pick one self-contained piece — a base entity class, a Doctrine helper, a form type, or a console helper — and use it in a single place. Do not adopt the bundle wholesale before you understand its assumptions.

Implementation Patterns

Treat the bundle as a curated set of conventions you extend, not a framework you build on.

• Selective adoption. Because it is opinionated and heterogeneous, import the specific traits/abstract classes you need rather than depending on the bundle as a whole. Keep the surface area small so a future removal is cheap.
• Entity base classes. If the bundle ships base entity/ID/timestamp abstractions, extend them for new entities but keep domain logic in your own classes. Verify the mapped superclass annotations/attributes match your Doctrine setup before rolling out.
• Service usage. Prefer constructor autowiring of the bundle's services over direct instantiation. Check autoconfiguration in the bundle's services.yaml; if services are not public, use type-hinted injection rather than pulling from the container.
• Configuration isolation. If the bundle exposes a config tree, put settings in a dedicated config/packages/<alias>.yaml and commit it. Avoid scattering its options across environment files.
• Version pinning. In composer.json, pin to a specific minor ("fusonic/framework-bundle": "~1.2.0") and commit composer.lock. With low adoption, an unexpected minor bump is a real risk.
• Fork-or-vendor discipline. For anything central to your domain, wrap the bundle's classes behind your own interfaces or extend them locally. This lets you swap or vendor-patch the package without touching call sites.
• Monorepo consistency. The bundle is designed for Fusonic's own projects; the most natural fit is standardizing shared base classes and helpers across several of your own Symfony apps.

Gotchas and Tips

• Community risk. 1 star and 0 dependents means minimal external validation. Audit the code you rely on, and assume you may need to maintain a fork.
• Opinionated defaults can conflict. Bundle services may assume specific Doctrine, security, or serializer configurations. Container compilation errors on first install usually mean an optional dependency or config key is missing — read the exception's service ID and check the bundle's services.yaml.
• Symfony version constraints. Check the require block carefully; a low-activity bundle may lag current Symfony LTS releases. Test on your target Symfony version before committing.
• Debugging registration problems. If the bundle "does nothing", confirm it is actually in bundles.php and that the extension alias matches what you put in YAML. Use debug:config and debug:container to verify services and parameters landed.
• Extension points. Prefer decoration (decorates:) or subclassing over editing vendor files. If you must patch, use a Composer patch plugin and document it.
• Deprecation and removal planning. Keep a note of every class you import from the bundle; if maintenance stops, that list is your migration checklist.
• Config quirks. If Configuration.php uses ->children() aggressively, unknown keys will fail loudly rather than silently — good for catching typos, but watch for keys renamed between versions.
• Don't couple core domain code. Keep the bundle at the edges (controllers, forms, console, infrastructure) and out of your domain model so abandonment is survivable.