Dependency Injection Laravel Package

Product Decisions This Supports

• Template-engine extensibility architecture: If we adopt Phug (the PHP Pug/Jade port) as a rendering layer, this package is the substrate that lets custom filters, keywords, and extensions receive services instead of instantiating them inline. That's a build-vs-buy decision about how we make templates extensible, not just whether we use Pug syntax.
• Build vs. buy for a DI container: Evaluates whether we write our own reflection-based auto-wiring for template extensions or consume this small MIT component. The answer is almost always "consume it" — the package is thin, PSR-11-aligned, and maintained alongside Phug, so it avoids bespoke glue code.
• Framework-container interop strategy: For Laravel teams, the real decision is whether Phug's container should wrap or delegate to Laravel's Illuminate\Container. This package's PSR-11 surface makes that bridging decision concrete: we can register Laravel-resolved services into Phug's container rather than introducing a parallel dependency graph.
• Feature scoping for template-level customization: If product wants designer-facing template extensions (custom filters, i18n helpers, asset resolvers), this package determines how cheaply those can be added per-feature without touching core renderer code.
• Roadmap risk assessment for the Phug dependency: Low stars (1) and zero dependents signal a niche, single-maintainer-org ecosystem. That informs whether we treat Phug as a strategic platform bet or a contained, replaceable rendering detail behind an internal interface.

When to Consider This Package

Adopt it when:

• We are already committing to Phug as the template engine and need its extension/filter resolution to work — this is effectively a required transitive piece, not an optional add-on.
• We want PSR-11-compliant resolution with reflection auto-wiring for template-layer classes without pulling in a heavyweight container (PHP-DI, Symfony DI) just for rendering.
• Our extension surface is small and template-scoped — a handful of filters/keywords that need a logger, config, or translator injected.
• We can bridge to Laravel's container with a thin adapter, keeping one source of truth for service definitions.

Look elsewhere when:

• We are not using Phug. As a standalone DI container it offers nothing Laravel's Illuminate\Container doesn't already provide, and adding a second container is a net negative for cognitive load and debugging.
• We need compiled/optimized containers, contextual bindings, tagging, or lazy proxies at application scale — PHP-DI or Symfony's container are the mature choices.
• Ecosystem durability is a hard requirement. One star and zero dependents means bus-factor and abandonment risk; if the rendering layer is business-critical, we should vendor it or wrap it behind an internal interface with an exit path.
• Team familiarity with Pug/Phug is absent — the syntax and extension model are a learning cost that only pays off if designers or existing templates already use it.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed plumbing component inside the Phug templating ecosystem — it's the piece that lets us add template features (custom filters, localization helpers, asset handling) cleanly instead of hard-coding dependencies into rendering code. It costs us nothing to adopt and reduces per-feature engineering effort, but it's a niche dependency with minimal community footprint, so we should treat it as an implementation detail behind our own interface rather than a platform commitment.

To engineering: It's a PSR-11 container with reflection-based auto-wiring, purpose-built for resolving Phug filters and extensions. The practical play is to register it as an adapter over Laravel's container so template extensions receive framework-managed services. Low risk, low cost, but isolated: pin the version, keep the integration behind a thin internal abstraction, and don't let Phug-specific container semantics leak into application code. If we're not on Phug, skip it — Laravel's container already covers this ground.