Redkite Labs Bootstrap Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package, and it is explicitly marked DEPRECATED / READ-ONLY. Treat it as a historical reference and a design lesson rather than something you will composer require into a Laravel app.

If you are evaluating it for a legacy Symfony 2.x project:

1. Check installability first — the bundle targets Symfony 2.x and PHP 5.3+, so composer require redkite-labs/redkite-labs-bootstrap-bundle will likely fail resolution on any modern PHP/Symfony constraint set. Do this in a throwaway branch before anything else.
2. Read RedKiteLabsBootstrapBundle.php plus the DependencyInjection/ extension and Configuration.php — the whole point of the package lives in how it reads Composer metadata and feeds a bundle list into the kernel.
3. Find where it hooks into AppKernel::registerBundles(). That is the seam you are replacing.
4. First real use case: stop hand-editing the registerBundles() array every time a dependency is added, and let the bundle derive that list from composer.json extra blocks and a config file instead.

For a Laravel developer, the fastest way to "get" this package is to compare it to Laravel's package auto-discovery (extra.laravel.providers / extra.laravel.aliases). It is the same idea, applied to Symfony2 kernels roughly five years earlier and without the framework blessing.

Implementation Patterns

Composer-driven bundle registration. The core pattern is declaring bundles in composer.json under an extra key and having the bootstrap bundle read vendor/composer/installed.json to resolve them. Day-to-day this means adding a dependency is one composer require and no kernel edit.

Environment-scoped bundles. Keep dev-only bundles (profiler, fixtures, debug toolbars) declared with an environment flag so prod does not boot them. Model this as a config array keyed by dev/test/prod rather than branching inside the kernel.

Manual fallback / hybrid mode. Always keep the ability to hard-code a bundle in registerBundles() for the cases the discovery layer cannot resolve. This is your escape hatch when a third-party bundle has no Composer metadata.

Ordering as configuration. Bundle order matters in Symfony2 (routing loaders, DI compiler passes). If the package resolves order from Composer's dependency graph, pin critical bundles explicitly; otherwise you inherit nondeterministic ordering from installed.json.

Lockfile-first reproducibility. Because registration is derived from installed packages, composer.lock becomes part of your application boot contract. Any workflow that runs composer update on a server is effectively editing your kernel at runtime — forbid it.

CI integration. Cache-warm step should run the equivalent of cache:clear / cache:warmup after composer install, since the resolved bundle list is baked into the compiled container. A stale container cache is the number-one source of "works locally, dies in CI" with this style of bundle.

Gotchas and Tips

• It is abandoned. READ-ONLY, 9 stars, zero dependents. There will be no fixes for PHP 8 deprecations, no Symfony 4/5/6 support, and no security patches. Do not introduce it into anything you intend to maintain.
• Autoload before boot. The bundle resolves classes via Composer's autoloader; if you register it before vendor/autoload.php runs (or via a custom autoloader), you get silent empty bundle lists rather than errors.
• Container cache is the trap. Bundle discovery happens at container compile time. After adding a dependency you must clear the Symfony cache, or the new bundle simply will not exist. debug:container --parameter=kernel.bundles is the fastest way to confirm what actually got registered.
• Ordering is implicit. Discovery order follows installed.json, which is not guaranteed to match your dependency intent. Any bundle that must load before another (routing, security, Doctrine migrations) should be pinned manually.
• Config merging surprises. If the DI extension merges bundle config from multiple sources, extension load() methods may receive arrays in an order your bundle's Configuration.php does not expect — validate with config:debug / debug:config.
• Extension point: the bundle-list resolver is the only sane place to customize. If you fork this at all, subclass the resolver rather than editing the bundle class, so you can swap in a Symfony Flex-style recipe later.
• Migration path is the real takeaway. If you are on Symfony 2.x, the destination is Symfony Flex (symfony/flex + config/bundles.php) — it solves exactly this problem with framework support. If you are on Laravel, you already have the equivalent in package discovery, so there is nothing here to port; study the pattern, skip the code.
• Name collision caution: despite the bootstrap in the name, this has nothing to do with Bootstrap CSS or laravel/ui. It is about application bootstrap.