Seigicms Framework Bundle Laravel Package

Getting Started

1. Confirm you can actually install it. The repo is a GitLab project, not necessarily Packagist. Check composer.json in the repo for the exact name (likely seigisoft/seigicms-framework-bundle) and its require block. With zero dependents and no stars, assume you'll add it as a VCS repository:

   "repositories": [{ "type": "vcs", "url": "https://gitlab.com/seigisoft/seigicms/seigicms-framework-bundle" }],
   "require": { "seigisoft/seigicms-framework-bundle": "dev-main" }
   

2. Check compatibility before writing code. Look at the Symfony version constraint, PHP version, and PSR-4 namespace in composer.json. If it targets Symfony 4/5 while you're on 6/7, stop and evaluate before investing time.
3. Register the bundle in config/bundles.php (Symfony Flex style):

   SeigiSoft\SeigiCms\FrameworkBundle\SeigiCmsFrameworkBundle::class => ['all' => true],
   

4. Look first at these files/directories — they tell you what "reusable components" actually means here:
   • src/DependencyInjection/ — the extension and Configuration.php (what knobs exist)
   • src/Resources/config/services.yaml — the services it exposes and their visibility
   • src/Contracts/, src/Interface/, or src/*Interface.php — the integration contracts other bundles implement
   • src/EventSubscriber/ and src/Event/ — the cross-bundle event surface
   • README.md and CHANGELOG.md if present
5. First use case: pick the smallest shared concern this bundle provides (e.g., a cross-bundle event or a base service) and wire one consumer bundle to it via autowiring. Verify with bin/console debug:container <service-id> that the service exists and is public/autowirable before building on it.

Implementation Patterns

Contract-based integration. The bundle's purpose ("reusable components to integrate between bundles") usually means it ships interfaces or abstract classes that sibling SeigiCMS bundles implement. Inject the interface, not the concrete class, and let the bundle's service definitions decide which implementation wins. This is the pattern that keeps your own bundle upgrade-safe.

Event-driven glue. When two bundles shouldn't know about each other directly, the framework bundle likely dispatches or defines events both can subscribe to. Create a small subscriber in your bundle:

class ContentCreatedSubscriber implements EventSubscriberInterface
{
    public function __construct(private SomeSharedService $service) {}

    public static function getSubscribedEvents(): array
    {
        return [SomeFrameworkEvent::class => 'onContentCreated'];
    }

    public function onContentCreated(SomeFrameworkEvent $event): void { /* ... */ }
}

Prefer this over direct calls into another SeigiCMS bundle's internals.

Service decoration instead of forking. If the framework bundle's default behavior doesn't fit, decorate its service in your app/bundle config rather than editing vendor code:

services:
  App\Cms\MyDecorator:
    decorates: seigicms.framework.some_service
    arguments: ['@.inner']

This is the cleanest extension point for a package with a tiny maintainer base — you stay upgradable.

Config merging via the bundle extension. If you need per-environment tuning, add settings under the bundle's config key in config/packages/*.yaml and confirm they flow through Configuration.php. Don't hardcode values that the bundle already exposes as config; the tree is your contract.

Compiler passes and tagged services. For "reusable components," expect tagged-service collection (e.g., registering integrations). If you're adding your own integration, look for an addCompilerPass or tag name in the bundle's build method and tag your service accordingly rather than manually registering it in a registry.

Test against a minimal kernel. Because there are no downstream users to validate upgrades, write an integration test that boots a kernel with just this bundle and your consumer. It's the only cheap safety net you'll have.

Gotchas and Tips

• Naming vs framework reality. Despite the "bundle" suffix and SeigiCMS branding, this is Symfony, not Laravel. There are no service providers or facades — bundle registration, the DI container, and the event dispatcher are your tools. A Laravel developer's instinct to call app()->make() has no equivalent here.
• Zero dependents means zero battle-testing. No one else is exercising this code path. Pin to a specific commit/tag, vendor-audit the source for eval, dynamic includes, or network calls, and read the whole src/ before trusting it in production. "Opportunity 30" signals a gap, not maturity.
• Private services. Modern Symfony makes services private by default. If debug:container shows the service you need but injection fails, check public: true in the bundle's services.yaml or use @service_locator — the bundle author may not have anticipated external autowiring.
• Config cache staleness. After editing the bundle config key or dropping in a new subscriber, run bin/console cache:clear. Stale container caches are the #1 source of "my service isn't there" confusion with small bundles.
• Circular dependencies. "Integrate between bundles" often means bundle A depends on the framework bundle and the framework bundle expects A's contract at compile time. If you hit a container compile error, isolate the dependency to runtime (service locator, lazy service) rather than constructor-time.
• Version constraints are your real risk. With no stars and no dependents, dev-main can change under you. Use a commit hash in composer.json and treat the repo as effectively read-only unless you're prepared to fork.
• Extension points to know: service decoration (.inner), tagged services, prependExtension in your own bundle's DI extension, and framework event subscribers. If the bundle lacks these, forking is the only safe path — record that decision explicitly.
• Debugging workflow: debug:container --tag=<tag>, debug:event-dispatcher, and debug:config <bundle_alias> will answer most "is it wired up?" questions faster than reading the source. If the README is thin (likely, given the metrics), the container is your documentation.