The base of the c975L ecosystem in a single package: ConfigBundle (database-backed configuration, EasyAdmin dashboard, user accounts, health check, sitemaps) and UiBundle (page blocks, media library, theme, legal models, forms, emails). Two bundles, one package, one release.
This is not a merged bundle. A Composer package is not a Symfony bundle: this package ships the two bundles unchanged, each with its own namespace, its own services.yaml, its own configs.json, its own translation domain and its own dashboard section.
CoreBundle/
├── composer.json ← the only one
├── ConfigBundle/ → c975L\ConfigBundle\
└── UiBundle/ → c975L\UiBundle\
There is no c975L\CoreBundle\ namespace. The name core-bundle exists on Packagist only.
ConfigBundle and UiBundle referenced each other in their composer.json, in both directions:
- Ui → Config is deep and deliberate:
ConfigServiceInterfaceis read everywhere, and every*ProviderInterfaceof the generic registry mechanism is declared in ConfigBundle. - Config → Ui comes from the dashboard itself (
FontRegistry,FormThemeRegistry,StylesheetManagementRegistry,ScriptAdminRegistry,WhatsNewRegistry) and from user accounts (Form/FormField+EmailService).
Two packages that require each other cannot be released independently, and neither can see the other's work-in-progress — only its last published version. They were never two layers; they were one layer billed as two. This package says so out loud.
composer require c975l/core-bundleThen register both bundles — they remain two entries:
// config/bundles.php
return [
// ...
c975L\ConfigBundle\c975LConfigBundle::class => ['all' => true],
c975L\UiBundle\c975LUiBundle::class => ['all' => true],
];Each bundle keeps its own README, unchanged:
Its history, on the other hand, is the package's: ChangeLog.md and UPGRADE.md carry both bundles from here on. Each bundle's own files stop at its last published release — v5.17.1 for ConfigBundle, v1.17.0 for UiBundle — and are kept as archives.
The six checks the CI runs live in composer.json alone, as one list:
composer qacomposer run -l names what each one covers, and each is callable on its own (composer audit-deps, cs, fixer, stan, stan-scaffold, test). The workflow calls those same scripts, so a check is never declared twice.
audit-deps is composer audit: it matches the resolved dependencies against the Packagist security advisories, which is where a known CVE in a dependency gets caught — before the push, not once a site has deployed it. Abandoned packages are reported without failing the run.
A development machine's vendor/ symlinks the sibling repositories, which expose code no tag has published yet — code the CI never sees. bin/ci.sh replays composer qa on a copy of the repository whose dependencies are resolved from Packagist, uncommitted changes included:
bin/ci.shSee UPGRADE.md. In short: replace the two requirements with c975l/core-bundle. No PHP use, no @c975LUi/… template reference, no translation key and no bundles.php entry changes — the namespaces are the same ones.
MIT — see LICENSE.