Framework Bundle Laravel Package

Getting Started

1. Install via Composer (check the composer.json require block first — the repo is low-traffic, so confirm the Symfony version constraint matches your app before installing):

   composer require rednose/framework-bundle
   

2. Register the bundle. In a modern Symfony app this usually means the config/bundles.php entry the Flex recipe (if any) adds, otherwise add it manually:

   // config/bundles.php
   Rednose\FrameworkBundle\RednoseFrameworkBundle::class => ['all' => true],
   

   The class name is whatever src/*Bundle.php declares — verify it, because small vendor bundles often don't ship a Flex recipe and you get no auto-registration.

3. Look here first, in this order:

   • README.md (often the only docs for small bundles)
   • src/ root for the bundle class and Resources/config/ (or config/) for the service definitions — the services tell you the actual public API surface
   • DependencyInjection/Configuration.php for the config tree (what keys you're actually allowed to set under rednose_framework:)

4. Configure only what the tree exposes:

   # config/packages/rednose_framework.yaml
   rednose_framework:
       # keys taken from Configuration.php
   

5. First real use case: extend or inject whatever the bundle exposes. For a bundle of this type the typical "first win" is reusing its abstract controller or its service helpers (request/pagination/templating) inside a freshly generated controller:

   bin/console make:controller DemoController
   

   Then swap in the bundle's base class or injected service and confirm bin/console debug:container rednose lists the services as public or aliased.

Implementation Patterns

• Extend the bundle's abstract controller rather than composing. Symfon bundles of this kind usually ship a Controller base that wires up templating, JSON responses, or flashes. Extending gives you the helpers for free; if the signature doesn't match your needs, prefer injecting the underlying services instead of fighting inheritance.

• Inject bundle services by interface/alias. After wiring, run bin/console debug:container --tag= and debug:autowiring to see what's autowirable. Even when the bundle doesn't declare autoconfiguration, aliasing a service to an interface in your own services.yaml is the cleanest integration point:

  services:
      Rednose\FrameworkBundle\SomeInterface: '@rednose_framework.some_service'
  

• Treat it as infrastructure glue, not domain code. Keep your own entities/controllers lean and call into the bundle for cross-cutting concerns (pagination helpers, response formatting, request parsing). This keeps you portable if the bundle is abandoned (realistic at 1 star / 0 dependents).

• Reuse its config in env-specific files. Split rednose_framework.yaml per environment (e.g. when@dev: blocks) if the bundle exposes debug/logging toggles — common in framework-level bundles.

• Test with the real container. Because integration is Symfony-level (service definitions, event subscribers), unit-testing the bundle's classes in isolation misses the point. Prefer a KernelTestCase that boots your app so the bundle's compiler passes and service wiring are exercised.

• Version-pin the bundle in composer.json (e.g. ^1.0) and commit composer.lock. With no dependents and 1 star, upstream churn or a disappearing branch is a real risk; pinning buys you a stable target.

Gotchas and Tips

• Assume sparse documentation. Verify everything against source: the config tree in DependencyInjection/Configuration.php, the service IDs in Resources/config/*.xml|yaml, and the bundle class name. Don't trust guesswork in blog posts.

• Service visibility. Older Symfony bundles define services as public: false by default but may rely on setPublic/aliases. If debug:container shows what you need as private and autowiring fails, either add an alias in your app or ->public() via a compiler pass in your own bundle.

• Bundle name mismatch. Check that RednoseFrameworkBundle::class actually exists — many small bundles rename the namespace without updating the README, causing a Class not found during cache:clear.

• Symfony version compatibility. The composer.json constraint tells you the supported major. Booting it on 7.x when it declares ^5.4|^6.0 often "works" until a deprecation or container API change breaks a compiler pass. Pin your Symfony minor and test the bundle against it.

• Config key prefix. Symfony's convention is the snake_case of the bundle name (rednose_framework), but small bundles occasionally use a different alias from getExtension()->getAlias(). If config/packages/rednose_framework.yaml is silently ignored, check the alias — an unknown key should raise a InvalidConfigurationException, otherwise you're writing to the wrong prefix.

• Cache and debug commands first. When something is off, bin/console cache:clear, debug:config rednose_framework, and debug:container will resolve ~90% of integration issues before you touch code.

• Extension points to keep in mind: the bundle's event subscribers (via getSubscribedEvents), its Twig extensions (verify ->getFilters()/->getFunctions()), and its compiler passes. Any of these is where you'd hook custom behavior if the shipped behavior isn't sufficient.

• Exit plan. With 0 dependents, budget for forking. Isolate calls to the bundle behind your own thin service so a future replacement is a one-file change rather than a grep-and-replace across the app.