Core Bundle Laravel Package

Getting Started

sfynx-project/core-bundle is a Symfony bundle from the Sfynx CMS/framework lineage. It is not a batteries-included app framework you adopt wholesale — it is a grab-bag of shared services, listeners, and Symfony glue that the Sfynx stack assumes is present. Treat it accordingly: install it, register it, then confirm what it actually wires before you build on top of it.

Minimal path:

1. Pull it in. It is not a mainstream Packagist package, so pin it explicitly and expect to use a VCS/path repository if the tagged release lags:

   composer require sfynx-project/core-bundle
   # or, from a fork/checkout:
   composer config repositories.sfynx-core vcs https://github.com/pigroupe/SfynxCoreBundle
   composer require sfynx-project/core-bundle:dev-master
   

2. Register the bundle in config/bundles.php (or app/AppKernel.php on older Symfony):

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

3. Find the extension alias before writing config. Open DependencyInjection/ and look for the Configuration tree — the alias is what goes under config/packages/. Do not guess it from the vendor name; bundles of this era frequently use a shorter alias (sfynx_core, sfynx, etc.).

4. First real use case: reuse the shared kernel plumbing. The highest-value immediate win is wiring the bundle's kernel event subscribers/listeners into your app so you inherit its request/response and routing behavior instead of reimplementing it. Inspect Resources/config/services.* (XML/YAML), then verify with:

   bin/console debug:container --tag=kernel.event_listener
   bin/console debug:event-dispatcher kernel.request
   

Where to look first, in order: composer.json (Symfony version constraint), SfynxCoreBundle.php (what it registers), DependencyInjection/Configuration.php (your config surface), then Resources/config/ (the actual service graph). Read those four before assuming any API.

Implementation Patterns

Layered usage (Sfynx style). The Sfynx ecosystem leans on a Presentation / Application / Domain / Infrastructure split. If you are adopting that style, the core bundle supplies the cross-cutting pieces (listeners, helpers, DI wiring) while your layers stay thin. Keep your src/ organized along those lines and let the bundle own the shared kernel services rather than duplicating them.

Inject the bundle's services, don't extend its classes. The most stable integration point is the service container. Autowire by interface where the bundle exposes one; where it only ships concrete classes, define an alias:

services:
    Sfynx\CoreBundle\SomeService:
        alias: sfynx_core.some_service
        public: true

Event-subscriber integration. Rather than subclassing the bundle's controllers or base classes (fragile across Symfony majors), listen to the events it emits or consumes. Register a small subscriber in your app that reacts to kernel.request / kernel.response / custom bundle events, and keep your logic out of the vendor tree:

final class SfynxBridgeSubscriber implements EventSubscriberInterface
{
    public function __construct(private SomeService $svc) {}

    public static function getSubscribedEvents(): array
    {
        return [KernelEvents::REQUEST => ['onRequest', 10]];
    }

    public function onRequest(RequestEvent $event): void { /* ... */ }
}

Configuration extension pattern. App-level knobs (cache TTLs, feature flags, route prefixes) belong in your config/packages/<alias>.yaml, consumed through the bundle's Configuration tree. If a setting is missing from that tree, prefer a compiler pass in your own bundle over forking the vendor config — it survives upstream updates.

Templating and helper reuse. If you use its Twig extensions, register them as services in your app and let the bundle's Resources/config supply the tag. That keeps the coupling to the service id, which is far more stable than the class name.

Wrap it. For anything business-critical, put your own thin adapter/facade in front of the bundle's classes. You get a single seam to mock in tests and a single place to patch when upstream changes.

Gotchas and Tips

• License is NOASSERTION. GitHub could not identify a standard license. Before this goes near production — especially in a company — open the LICENSE file in the repo and get it reviewed. Do not assume MIT. This is the single biggest blocker here, not the code.

• Five stars, zero dependents, low activity. You are effectively on the bleeding edge. Pin to a specific commit ("require": { "sfynx-project/core-bundle": "dev-master#<sha>" }) and vendor-lock it. Assume you may need to fork; budget for that from day one.

• Symfony version drift. Check composer.json for the Symfony constraint. Bundles from this generation often target 2.x/3.x/4.x idioms — explicit XML service definitions, public: true services, no autowiring, possibly deprecated event classes. On modern Symfony (6/7) you will hit removed APIs (Swiftmailer, Kernel::VERSION gates, getSubscribedEvents signature changes). Test the install on your exact Symfony version immediately, before writing any code.

• The extension alias rarely matches the vendor name. SfynxCoreBundle might register as sfynx_core, sfynx, or something else. Confirm in DependencyInjection/*Extension::getAlias(). Wrong alias = silently ignored config, which is a miserable debug session.

• Services may be private by default. Calling $container->get('sfynx_core.something') from a controller will throw on modern Symfony. Either alias the service publicly in your config (shown above) or — better — inject it.

• Autowiring may not work out of the box. If the bundle's Resources/config/services.xml doesn't declare autowire, you must wire by hand. Run bin/console debug:container --show-private | grep -i sfynx to see what's actually registered.

• Debugging playbook: debug:container --tag=kernel.event_listener, debug:event-dispatcher <event>, debug:router, debug:config <alias>. If debug:config reports the alias unknown, the bundle isn't registered or the alias is wrong — that's your first check.

• Extension points, in order of safety: (1) your own event subscribers, (2) a compiler pass in your app bundle, (3) service decoration (decorates:), (4) forking. Prefer (1)–(3). Decorating a bundle service is usually cleaner than overriding its config.

• Clearing cache is mandatory after config changes. These older bundles cache the compiled container aggressively; a stale var/cache will make you chase phantom bugs. bin/console cache:clear between config edits.

• Don't put business logic in the vendor tree. Any local edits will be lost on the next composer update. If you must patch, fork and require your fork — and record the diff so you can rebase.