Default Laravel Package

Product Decisions This Supports

A decision about one narrow convention: how our code produces "the empty/sensible default" of a domain object. The package is a single contract — DefaultInterface with one method returning static — plus the naming convention that goes with it. That makes it a coding-standard decision, not a platform bet. Frame it that way internally and it stays cheap; oversell it and it becomes noise.

• Feature/architecture decision — kill the "what is empty?" ambiguity. Today our code likely mixes null, [], new Foo(), and hard-coded config arrays for the same concept (guest user, empty cart, failed API response, default shipping address). Adopting the interface forces one named, discoverable entry point (Foo::getDefault()) per concept. That is a real reduction in surface area for edge-case bugs — but only for classes where "the default" is a meaningful domain concept.
• Build vs. buy: this is closer to "buy a naming convention for free, or vendor it." MIT, zero dependencies, no runtime magic, one file's worth of contract. The honest comparison is not "build vs. buy" but "adopt the dependency vs. copy the interface into our own App\Support namespace." At ~1 star and 0 dependents, the supply-chain argument for depending on this specific package is weak; the value is in the convention, which we can own ourselves in an afternoon.
• Roadmap inputs it informs:
  • Modularization / package extraction. If we plan to split domain code into internal packages or add a plugin surface, a shared default contract gives downstream consumers a predictable entry point. This is the strongest genuine justification.
  • API response contracts. If we have endpoints that return null vs. {} vs. [] inconsistently on failure, standardizing defaults is a small, low-risk reliability win that shows up in API docs and client behaviour.
  • Test fixture strategy. A getDefault() convention can replace bespoke mock setup — but treat the popular "30–50% faster test setup" claim as unverified marketing until we measure it on two of our own test suites.
• Explicit non-goals / where it will not help: it is compile-time and static. Anything needing per-user, per-tenant, database-driven, or locale-dependent defaults stays in config/DI, not here. Do not let it spread into a pseudo-factory.
• Strategic read on the ecosystem: the package is part of the larger php-standard-library monorepo (the split repos just mirror its releases). Its value to us is only through that larger library; taking this repo alone as a dependency is hard to justify — take the monorepo or take nothing.
• Scoping decision I'd expect from this assessment: a bounded pilot on 2–3 classes where default ambiguity has actually caused incidents or support tickets, with a documented go/no-go on whether we depend on the package or inline the interface.

When to Consider This Package

Adopt if:

• You have concrete, recurring defects or support tickets traceable to inconsistent default values (null-vs-empty bugs, client-side surprises on failed responses, guest/anonymous entity mishandling). This is the only strong signal.
• You are extracting internal packages or adding a plugin/module surface and want third parties to be able to obtain a canonical instance of your types without constructor archaeology.
• Your team is already standardizing on PSR-style contracts and would rather add a one-method interface than a custom convention nobody documents.
• Your domain has rich value objects / DTOs / config objects where new Foo() is not a valid construction and a named default carries real meaning.
• You are already considering php-standard-library as a whole; then this cost is effectively zero and rides along with a broader decision.
• You want the convention and are comfortable either depending on a near-zero-adoption package or copying the interface into your own namespace (my default recommendation for a team of any size).

Look elsewhere (or skip) if:

• Your "defaults" are trivial ([], null, 0). An interface for return [] is ceremony.
• Laravel/Framework primitives already cover it — Collection::empty(), Model::make(), optional(), config repositories, Null object patterns via DI. Check the framework first; several of the use cases this package claims are already solved natively.
• You need runtime, per-tenant, or data-driven defaults. Different problem; solve it with config + container bindings.
• Your codebase is small or your team is small. At that scale the convention is unnecessary and the dependency is pure overhead.
• Dependency governance risk is a blocker. 1 star, 0 dependents, single upstream project, release notes that just point at a monorepo. If your org requires a maintenance/adoption bar for third-party packages, this fails it — which is fine, because the cost of inlining is minutes.
• You're below PHP 8.0 (the static return type) or you're pre-Laravel DI maturity where you can't bind defaults cleanly.
• You already have a house convention (::empty(), ::blank(), a NullObject trait) and churn would cost more than consistency gains.

Due diligence before adopting: verify the release cadence and maintainer responsiveness on the main monorepo, not this split repo; confirm the licence chain across transitive monorepo packages; pin the version; and check that the static return type in a shared contract doesn't conflict with existing interfaces (e.g., if a class already extends a base with a clashing signature).

How to Pitch It (Stakeholders)

Executive summary (one paragraph). We have a recurring, low-grade class of defects caused by different parts of the codebase disagreeing on what "empty" means — sometimes null, sometimes an empty object, sometimes a hardcoded value. This package is a one-method interface that gives each concept a single, named default. It is MIT-licensed, has no runtime dependencies, and adds no meaningful performance cost, so the downside is small. The upside is real but modest: fewer edge-case bugs, a cleaner story for our modular/plugin roadmap, and a more predictable API surface. It is not a strategic bet and it is not a large initiative — I recommend a bounded pilot on two or three classes where this has actually bitten us, measured against current bug and test-setup data, before deciding whether to depend on the package or simply adopt the convention in-house. My honest prior is that the convention is worth having and the dependency probably isn't.

For engineering (the decision they actually need to make).

• What it is: a contract with a single method returning static, giving classes one canonical default instance. Framework-agnostic, no magic, no service provider.
• Why not just DI? It complements DI — bind Foo::getDefault() in a provider where you need it injected; use the interface where you need a type-level guarantee that a default exists.
• Proposed pilot: pick 2–3 classes with documented default-related bugs (candidates: a failed-response DTO, an anonymous/guest entity, a config value object). Implement the contract, replace ad-hoc defaults, and measure: defect count in that area, test-setup lines/time, and reviewer confusion.
• Open question we should answer in the pilot: do we take the dependency, or vendor the interface into App\Support? Given adoption numbers, vendoring is defensible and removes a supply-chain line item.
• Tradeoffs, stated plainly: one interface per participating class; a small amount of ceremony; a hard rule needed so it doesn't get used for trivial or dynamic defaults. No known runtime risk — it's a contract, so it can be piloted and reverted cheaply.
• Success criteria: measurable reduction in default-related defects, no new confusion in code review, and a clear rule in our coding standards for when a class may implement it.

For QA/test teams. If a class implements the contract, getDefault() gives you a predictable starting object instead of a hand-built mock. That should make some fixtures shorter and less brittle, and it keeps test data aligned with production behaviour. Please treat the widely-quoted setup-time savings as a claim to validate, not a promise — we'll measure it during the pilot and drop the convention if it doesn't hold.

For product managers. This is a plumbing change with a small, indirect user-facing benefit: fewer cases where a user sees an error or an odd empty state because two parts of the system disagreed about "nothing here." No feature work, no user-visible roadmap shift. The one roadmap item it genuinely de-risks is modularization/plugins, where we want external modules to be able to get a valid instance of our types without guessing. Treat it as a hygiene ticket with a short pilot, not a project.