Resource Bundle Laravel Package

Getting Started

Minimal path from zero to first working call:

1. Install

   composer require igdr/resource-bundle
   

   Note the installed version — with 0 stars and 0 dependents you want to pin it ("igdr/resource-bundle": "x.y.*") and commit composer.lock immediately.

2. Register the bundle in config/bundles.php:

   return [
       // ...
       Igdr\ResourceBundle\IgdrResourceBundle::class => ['all' => true],
   ];
   

3. Inspect before configuring. Since documentation is thin, let the container tell you what the bundle exposes:

   php bin/console debug:container --parameters | grep -i igdr
   php bin/console debug:container --tag=igdr
   php bin/console config:dump-reference igdr_resource   # guess the alias from the service IDs above
   

4. Create the config file at config/packages/igdr_resource.yaml based on the dump from step 3. Start empty (igdr_resource: ~) and only add keys you can confirm from config:dump-reference.

5. First use case: fetch the bundle's primary service (likely a resource manager/registry under Igdr\ResourceBundle\…) via constructor injection and exercise it in a scratch controller or bin/console command. Confirm the service is public or autowired before wiring it deep into an application layer.

Where to look first: the vendor/igdr/resource-bundle/ tree itself. Check Resources/config/services.* and DependencyInjection/Configuration.php — these are the source of truth for service IDs, tags, and config keys, and will be more reliable than any README.

Implementation Patterns

• Constructor injection over container lookups. Bind the bundle's manager/registry service to your own abstraction (an interface in your domain layer) so you can swap or shim it later if the package stalls.

  # config/services.yaml
  App\Resource\ResourceGateway:
    alias: 'igdr.resource.manager'   # confirm real ID via debug:container
  

• Tag-based extension. Bundles of this shape usually rely on a compiler pass and tags (e.g. igdr.resource.handler). Register your own handlers by tagging services rather than editing vendor code:

  App\Resource\Handler\ImageHandler:
    tags: ['igdr.resource.handler']
  

• Configuration-driven resources. Define resource types/mappings in igdr_resource.yaml and keep the YAML in version control per environment. Override per-env with config/packages/dev/igdr_resource.yaml rather than conditional logic in PHP.

• Controller integration. Wrap calls in a thin application service (ResourceService) so controllers and console commands share one entry point. This isolates you from the bundle's API surface changing on a patch release.

• Event/listener hooks. If the bundle dispatches events (check debug:event-dispatcher | grep -i igdr), prefer listeners over subclassing vendor classes — subclassing ties you to internal implementation.

• Testing. Write one integration test that boots the kernel and asserts the bundle's key service resolves (self::assertTrue($container->has('igdr.resource.manager'))). This is your early-warning system for a broken upgrade.

• Fallback strategy. Keep the bundle behind an adapter interface and have a null/second implementation ready. With no dependents to lean on, this is your exit ramp if the package is abandoned.

Gotchas and Tips

• Low maturity risk is the headline. 0 stars, 0 dependents, score 0.03 means: no community, no Stack Overflow answers, no third-party blog posts. Budget time for reading vendor source directly and expect to debug by var_dump/dd() rather than searching.
• Verify Symfony and PHP compatibility before installing. Check composer.json in the vendor tree for symfony/* version constraints and PHP ^ requirements. A bundle this small may target an older Symfony major.
• The config alias may not match the package name. igdr/resource-bundle does not guarantee igdr_resource as the alias. Run debug:container --parameters and grep for the actual key; guessing wastes time.
• Bundle class name and namespace may differ from the Composer package. Confirm the FQCN in composer.json's autoload section before adding to bundles.php — a wrong FQCN yields a confusing "class not found" at cache warm.
• Clear the cache aggressively when changing bundle config: php bin/console cache:clear. Compiler passes and config dumps can go stale and make working config look broken.
• Debug with debug:container, debug:config, and debug:event-dispatcher — not with docs. These three commands answer 80% of "how does this bundle want to be used" questions.
• Watch for public/private service changes. If the primary service is private, alias it explicitly in your own services.yaml (see Implementation Patterns) rather than using $container->get() in a controller.
• Extension points to look for in vendor source: compiler passes (DependencyInjection/Compiler/), tags, event classes (Event/), and interfaces you can implement. Prefer each of these over forking the bundle.
• Pin and lock. Use an exact version constraint and treat any upgrade as a manual review of the vendor diff — there is no upstream changelog discipline you can rely on for a package at this stage.
• Have an exit plan documented. Because the bundle sits behind an adapter interface, replacing it with in-house code should be a scoped, single-PR change, not a rewrite. Sketch that adapter early.