Dice Laravel Package

Product Decisions This Supports

• Build vs. buy for the DI layer. Dice is a ~single-purpose, dependency-free container. If the question is "do we write our own wiring/autowiring code or adopt something," Dice is the cheap third option: no config files to author, no framework attachment, no service-provider registration ceremony.
• Architecture: decoupling framework from domain. Dice is framework-agnostic, so it supports the decision to keep core business logic in plain PHP and only lean on Laravel at the edges. That makes future framework migrations, CLI workers, queue consumers, and standalone package extraction cheaper.
• Roadmap for legacy retrofits. Dice's rule/substitution model lets you swap concrete classes for interfaces without editing legacy constructors — a rare property that turns a scary "rewrite the monolith's wiring" epic into an incremental, ticket-sized refactor.
• Testing strategy. Constructor injection plus container-level substitution gives a standard seam for mocking and test doubles, reducing the "we can't test this because it news-up its dependencies" backlog.
• Packaging and SDK decisions. For internal Composer packages or a public SDK that must not depend on illuminate/*, Dice provides DI without dragging the framework in as a transitive dependency — a real decision point when publishing libraries to outside consumers.
• Scope control on the container. Choosing a deliberately minimal container constrains how much "magic" the codebase can accumulate (no annotations, no YAML graph), which is a governance decision about onboarding cost and debuggability.
• Performance/ops posture. No compilation step and no cache warmup to operate, which simplifies deploy pipelines for small services — worth weighing against Symfony DI's compiled container for high-throughput paths.

When to Consider This Package

Consider Dice when:

• The codebase is plain PHP, a microservice, a CLI tool, or a Composer library — not a Laravel app where Illuminate\Container already exists.
• You need autowiring with surgical overrides (bind an interface to an implementation by rule, not by editing every call site) and want to avoid writing a config graph.
• You are progressively retrofitting DI into legacy code where constructors and instantiation sites are numerous and you can't change them all at once.
• You want a small, auditable dependency surface — few files, no config parser, quick to read end-to-end during code review.
• The team is small and prefers explicit, readable wiring over framework convention.

Look elsewhere when:

• You are inside a Laravel application and only need DI for app code. Adopting Dice there means maintaining two containers with overlapping responsibilities — a net complexity increase with no user-facing benefit.
• You need strict PSR-11 conformance and a large ecosystem, attribute-driven injection, lazy proxies, or container compilation: evaluate PHP-DI, Symfony DependencyInjection, or League\Container instead.
• Maintenance currency matters. Last release is January 2023; verify supported PHP versions against your runtime target and confirm the project accepts patches before you make it load-bearing.
• You need vendor-backed support, security SLAs, or a long-term-support commitment — 435 stars is a healthy niche project, not a supply-chain safety net.
• Your architecture needs container-level features (decorators, tagging, contextual binding, service providers) that Dice intentionally omits.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source utility that removes hand-written object-wiring code from our PHP services. The business case is cost avoidance and optionality, not new capability: it lowers the cost of testing, makes it cheaper to extract services out of the monolith, and prevents framework lock-in in code we may want to package or sell. Adoption cost is measured in hours, not sprints, and it adds essentially no operational burden — no new infrastructure, no runtime service, no license fee. Principal risk is maintenance: the project's last release was early 2023, so we should treat it as a thin, replaceable utility rather than a strategic platform dependency.

For engineering (the ask): Isolate wiring in a container, program against interfaces, and get test seams without a framework. Dice gives you zero-config autowiring plus rule-based substitution — you can retrofit DI into legacy classes without touching their constructors, which is the hard part of every refactor we've deferred. It is deliberately minimal: no config files, no annotations, no compilation step, and it's readable in an afternoon.

Decision framing to put in front of the room:

• Recommend: Use Dice in non-Laravel PHP code, internal libraries, and legacy retrofits.
• Do not recommend: Introducing it alongside Laravel's container in existing Laravel apps — standardize on one container per application.
• Exit criteria: Keep the container behind a thin internal interface; if the package goes stale on our runtime, swapping to PHP-DI or Symfony DI should be a contained change. Verify license compatibility and PHP version support before shipping to external consumers.
• Success measure: Reduction in untestable classes and in the number of files touched per interface swap after 1–2 quarters.