Yumyum Laravel Package

Technical Evaluation

What we actually know. The package is published under the doublethreedigital vendor (Duncan McClean, a recognised maintainer in the Laravel/Statamic addon ecosystem) and points at a duncanmcclean/yumyum repository. That vendor mismatch is the first thing to close out — not because it is suspicious, but because supply-chain provenance is a five-minute check and a TPM should not sign off on a dependency whose published artefacts cannot be tied to a reviewed source commit. Beyond that, the description tells us it is a "small, focused piece of functionality" behind a "clean, expressive API," installs via Composer with auto-discovery, and publishes a config file. That is a description of the packaging convention, not of the functionality. We do not currently know what the package does, and that is the single largest gap in this evaluation.

Architecture fit. Mechanically, it conforms to Laravel package norms: service provider, extra.laravel.providers auto-discovery, publishable config under config/yumyum.php. That means it will drop into a conventional app without bespoke bootstrapping, and it is coverable with Pest/PHPUnit. Fit is therefore likely fine at the framework level. The unresolved question is scope, and scope determines blast radius: a CLI helper or a dev-only utility is a low-stakes convenience, while anything that mutates stored content, writes to the filesystem, or runs on the request path is a different category of decision entirely. A TPM should treat "what does it touch?" as the gating question, not "does it install?"

Adoption signal is absent, not merely weak. Zero stars, zero dependents, score 0. This is not proof of poor quality — good packages are often young or deliberately niche — but it means nobody else has absorbed the discovery risk for us. There are no third-party bug reports, no evidence of surviving a real Laravel major upgrade, and no downstream consumers to observe. If we adopt, we are the earliest substantial adopter, and the first production failure will be ours to find.

Principal risks.

Key questions (owner: engineering, half a day). What does this actually do, and does the framework or a ~20-line internal helper already cover it? Is it a runtime require or require-dev? Does it ship migrations, publish config, or write to the content repository? What is the tagged-release history, last commit date, and is there CI? What are the composer.json constraints versus our supported PHP/Laravel range? What is the licence, and can we legally vendor it? Each answer moves this from "unknown" to "decidable."

Integration Approach

Stack fit checks before any code. Verify the PHP and illuminate/* constraints against our runtime matrix; confirm auto-discovery is declared (and know the manual registration path for Laravel 11+ bootstrap/providers.php if it is not); confirm whether the config publish step is required or optional; and determine whether this belongs in require or require-dev, because a dev-only dependency never reaches production and that materially changes the risk profile.

The decision a TPM owns is build vs. buy vs. fork. For a package of this shape, all three are cheap and the honest comparison is total cost over the life of the feature, not technical elegance:

• Buy (Composer dependency): ~1 hour to install and pin. Cost is ongoing governance plus abandonment risk. Justified only when the capability is genuinely peripheral and the package is actively maintained.
• Fork-and-vendor: ~1 hour to copy the tagged source into our namespace with the licence header intact, plus the cost of ownership. Eliminates both the repository-disappears risk and silent upstream breakage. Recommended default at this adoption level.
• Build: a half-day internal implementation behind a small interface. Justified whenever the capability proves to be small — and with zero adoption signals, this is a live option rather than a fallback.

Migration path and containment. Whichever route we take, put a single adapter in front of it: an internal interface, one implementing class that delegates to the package, bound in a service provider. Call sites never see the vendor API, so swapping to an internal implementation later is a one-file change rather than a codebase-wide grep. Pin an exact version (1.0.* or better, a commit hash), commit the lockfile, and record the choice in the dependency register with a named owner.

Sequencing — a capped, timeboxed spike with a pre-agreed exit.

1. Scope discovery (0.5 day). Clone, read src/ and composer.json, run any shipped tests, answer the six questions above. This step alone may end the evaluation.
2. Sandbox (0.5 day). Install in a throwaway app, exercise the happy path and one failure path, and — if there is any write surface — snapshot the content directory and diff before/after.
3. Decision gate. Adopt as pinned dependency, fork-and-vendor, reimplement internally, or drop. Write the decision down with its rationale; that document is the deliverable, not the integration.
4. Staged rollout. Behind a config flag in a single non-production environment, then production. Only after that do we consider it settled.

Success criteria should be set before the spike, not after. For example: the package is adopted only if it saves at least two days of internal work, ships a tagged release within the last twelve months, declares support for our Laravel version, and can be removed in under an hour. If the criteria are not met, the answer is no — and that is a successful outcome of the evaluation, not a failed one.

Operational Impact

Maintenance. Assume we are the maintainers from day one. That means a named code owner, an entry in the dependency register, and a standing item on the major-upgrade checklist so the package is re-validated at every Laravel and PHP bump rather than discovered as broken during one. If we vendor it, this is literal: the code is ours, in our repository, reviewed under our standards.

Support. There is no SLA, no security advisory process beyond GitHub issues, and a maintainer whose commercial Statamic portfolio will always take priority over an unadopted utility. The escalation path is "we fix it ourselves." That is acceptable for internal tooling and prototypes; it is not acceptable for anything on a revenue path, a compliance path, or a customer-facing surface with a commitment attached. State this boundary explicitly in the adoption record so it does not quietly erode six months later.

Scaling. Most likely this is CLI-only or a build-time helper, in which case runtime scaling impact is zero and the operational story is simple. If it executes on requests, audit for N+1 queries, unbounded collection loads, and any in-process caching that breaks under multi-node deployment before it goes anywhere near production traffic.

Failure modes and pre-agreed responses.

Ramp-up. Low. A mid-level Laravel developer familiar with service providers and Composer will be productive in half a day, and the source is small enough to be read in full in an hour. The real ramp-up cost is governance, not learning: writing the adapter, registering the dependency, and establishing the upgrade-review habit. That overhead is why fork-and-vendor is the recommended posture for packages at this adoption level — it makes the ownership cost explicit rather than contingent.

Communication. Tell stakeholders this is a timeboxed trial behind a wrapper with a documented exit, not a platform bet. The downside is capped at roughly a day of engineering effort; the upside is pulling a low-differentiation slice of the roadmap forward. If anyone argues it should become core infrastructure, that is the signal to replace it with first-party code.