Yumyum Laravel Package

Getting Started

doublethreedigital/yumyum is a small, single-maintainer Laravel utility with essentially no public adoption (0 stars, 0 dependents, no score). That changes your first move: with a well-worn package you skim the README and start coding; with this one you spend the first ten minutes reading source, then write a throwaway call to prove it boots against your Laravel version.

composer require doublethreedigital/yumyum

Read these four things, in order, before writing application code:

1. vendor/doublethreedigital/yumyum/composer.json — the require block tells you the supported PHP and illuminate/* range. Confirm it matches your stack. Check extra.laravel.providers (and aliases, if any): if present, auto-discovery registers the provider; if absent, register it yourself (bootstrap/providers.php on Laravel 11+, config/app.php on 10 and below). Don't assume discovery just because the metadata says "Laravel package."
2. README.md — short by the sound of it. Treat it as an index of the public API, not documentation. It tells you what the package thinks it does; the source tells you what it actually does.
3. src/ — find the service provider first. Whatever it binds, merges, publishes, or loads (config, migrations, routes, commands, Blade components, facades) is the real surface area. The YumYumServiceProvider::register() and ::boot() methods are the map.
4. tests/ — if tests ship, they are your best usage examples. Read them before the README. The assertions encode the intended contract, and the setup fixtures show the happy-path configuration.

First use case: pick the smallest end-to-end exercise — one call from php artisan tinker, or a throwaway route — and confirm it works before designing anything around it. Do this on day one, in a branch, and record the exact version you installed (composer show doublethreedigital/yumyum). Because there is no community footprint, "does it boot on Laravel 11" is a genuine open question, not a formality.

Publish the config only if you need to override something. The description says config publishes to config/yumyum.php; a published config file becomes a maintenance item you must re-diff on every package upgrade. Publish it into a branch, review the diff against the package's own default, and commit only if you actually change a value. Otherwise leave it unpublished and rely on the defaults.

Decide require vs require-dev on day one. If the package is tooling (a command, a build helper, a dev-only convenience), it belongs in require-dev and stays out of your production build. If it runs on requests, it belongs in require — but see the risk notes below before you cross that line.

Implementation Patterns

Put an adapter in front of it. This is the highest-leverage decision with a package like this. Define a small interface in your app (App\Contracts\Whatever), implement it in one class that delegates to YumYum, and bind it in a service provider. Day-to-day application code depends on your interface; the vendor API appears in exactly one file. When the package goes unmaintained, ships a breaking 0.x-style minor, or fails a Laravel upgrade, you rewrite one class instead of grepping the codebase.

// App\Contracts\ThingContract.php
interface ThingContract
{
    public function doTheThing(string $input): string;
}

// App\Services\YumYumThing.php
final class YumYumThing implements ThingContract
{
    public function doTheThing(string $input): string
    {
        return \DoubleThreeDigital\YumYum\YumYum::make()->thing($input);
    }
}

// App\Providers\AppServiceProvider.php
$this->app->bind(ThingContract::class, YumYumThing::class);

Now every call site is app(ThingContract::class)->doTheThing($x) — and the vendor surface is a single class you can swap.

Wrap calls in an action or service class, not in controllers or Blade. Even without the interface, never call the package directly from a controller, a Blade view, or an Eloquent model. The indirection costs one class and buys you testability (mock the wrapper, not the vendor) and a migration path.

Test against your wrapper, not against the package. Your test suite should assert your behaviour. Add one or two integration tests that exercise the real package to catch the day the vendor's defaults change under you — but don't let the rest of the suite depend on third-party internals.

Pin exactly and commit the lockfile. Use a narrow constraint ("doublethreedigital/yumyum": "1.0.*" or even an exact version) rather than ^1.0. With zero dependents, no one upstream has validated 1.x minors against current Laravel; a composer update should never quietly move it.

Gate the first rollout behind a config flag. Add yumyum.enabled to your own config, or route through your wrapper's binding, and enable in one environment first. This is a discipline worth keeping for any unvalidated dependency, and it's cheap.

If you find yourself reaching for it more than twice in a sprint, that's the signal to write down what you use. List the exact methods you call and the exact behaviours you rely on. If that list fits on half a page — likely, given the package's shape — an internal implementation of ~20 lines, or a fork-and-vendor of the relevant src/ files under app/Support/, becomes genuinely attractive. Retain the license header if you fork.

Gotchas and Tips

Auto-discovery is not guaranteed. The package description mentions it, but check composer.json extra.laravel.providers before assuming. If it's missing, the failure mode is a confusing "class not found" or "method does not exist on null" because the container never bound anything. Register the provider manually in that case.

Zero dependents means zero upgrade coverage. Nobody has run this package on your exact Laravel + PHP combination in production, as far as Packagist knows. Before you merge, run php artisan about, check your framework minor, and verify the package's declared constraints include it. The common failure points in dormant packages are deprecated str_*/Arr::* helpers and facade signature changes.

Publishing config is a one-way door you should walk through carefully. Once config/yumyum.php is in your repo, it will silently shadow the package's future defaults. Every composer update should be followed by a diff of your config against the vendor default — or better, publish it to a scratch directory and copy only the keys you actually change.

Watch for write surface. If the package touches the database, filesystem, or (if Statamic-flavoured) the content directory, prove that path first on a snapshot. Diff the affected area before and after a run. A bug in a read helper is a broken page; a bug in a write helper is a data-integrity incident — and with no test suite and no dependents, you are the first line of discovery for that bug.

Debugging: tinker before dd(). Because the package is small, the fastest debug loop is php artisan tinker, instantiate or resolve the class by namespace, and poke at it. If it exposes a facade, Facade::spy() or a Log::listen in a throwaway route will usually reveal what's happening faster than stepping through your app. If it's a command, php artisan <name> -vvv and the provider's commands() array will show the shape.

Extension points. If the provider binds anything to the container under a string key — a driver, a client, a formatter — that is your extension point, even if there's no documented contract. Look at the bind/singleton calls in register() and at whether config/yumyum.php references classes. Overriding those config entries is a supported-looking way to change behaviour without patching the package.

If you find a bug, note the date, version, and a reproducible snippet in your dependency register. With a solo maintainer and no open-issue history to infer responsiveness from, assume you may need to fork the fix and carry it as a patch. Keep the fork small enough that it can be dropped the day upstream ships the same fix.

Keep it off the request path where you can. If the package is CLI-only or a build helper, its runtime scaling impact is zero — the low-risk case. If it executes per request, watch for N+1 queries and unbounded collection loads, especially under multi-node deployment where any in-memory caching it does will not be shared.

Re-evaluate on every major Laravel or PHP bump. Add the package to the dependency-review checklist. If upstream is inactive at the next major upgrade, the correct move is to replace it with your own implementation or a vendored copy, not to wait and hope. The adapter you built in Implementation Patterns makes that a one-day task rather than a rewrite.