Tomato Sauce Laravel Package

Getting Started

tomatophp/tomato-sauce is early-stage (v1.0.2) and the release history so far is infrastructure-focused rather than feature-focused. Start with the package's service provider and config file — those are the two places where behavior is defined at this version.

Minimal setup:

composer require tomatophp/tomato-sauce
php artisan vendor:publish --provider="TomatoPHP\TomatoSauce\TomatoSauceServiceProvider"

Then inspect config/tomato-sauce.php. At v1.0.2 the most notable change is a config path fix (PR #1), so the published config location and the path the package reads from are now expected to line up. If you are installing fresh, this should be transparent; if you are upgrading from v1.0.0/v1.0.1, see Gotchas.

First use case: treat the package as a configuration-backed integration point. Publish the config, commit it to the repo, override environment-specific values via .env, and consume the resolved config from your own service provider or action class. Do not scatter direct config('tomato-sauce...') calls across views — wrap access in a small helper or typed config object so the upcoming v1.x API churn is contained in one place.

Where to look first, in order:

1. README.md — the usage section is the authoritative API surface at this version.
2. config/tomato-sauce.php — every supported key and default.
3. src/*ServiceProvider.php — what is bound into the container, what is published, and under which tags.
4. composer.json — Laravel version constraints and whether the package uses package-discovery.

Implementation Patterns

Config-first integration. The package currently exposes behavior through configuration. The clean pattern is:

// config/tomato-sauce.php is published and committed
// .env carries environment-specific overrides
TOMATO_SAUCE_DRIVER=...

// app/Providers/AppServiceProvider.php
public function register(): void
{
    $this->app->singleton(MySauceConfig::class, fn () => MySauceConfig::fromArray(
        config('tomato-sauce')
    ));
}

This gives you a single seam to adapt when the package's config keys change.

Publish-and-pin workflow. Because this is a young package, pin the version in composer.json ("tomatophp/tomato-sauce": "^1.0.2") and re-run vendor:publish deliberately after each upgrade rather than relying on auto-merge. Diff the published config against the vendor copy before committing.

Testing. Config-driven packages are easy to test without booting the full integration:

protected function setUp(): void
{
    parent::setUp();
    config()->set('tomato-sauce.some_key', 'test-value');
}

Reset config between tests if you mutate it globally — Laravel does not roll back config() changes automatically.

TomatoPHP ecosystem integration. If you are using this alongside TomatoPHP admin panels, register the package's service provider before your panel providers so any container bindings it performs are available when panel routes and menus are built. Do not assume menu/route registration exists at v1.0.2 — verify in the service provider before wiring UI.

Upgrade discipline. For a 1.0.x package with one contributor-driven fix so far, treat every patch as potentially behavior-changing. Run php artisan config:clear && php artisan optimize:clear after upgrade, then smoke-test the code path that reads the published config.

Gotchas and Tips

The v1.0.2 config path fix is an upgrade hazard. If you installed v1.0.0 or v1.0.1 and published the config, the file may have been published to a path the package was not actually reading. After upgrading:

php artisan vendor:publish --provider="TomatoPHP\TomatoSauce\TomatoSauceServiceProvider" --force
php artisan config:clear

Diff the result. --force will overwrite local edits, so stash your customized config first.

Config caching masks path issues. A stale bootstrap/cache/config.php will happily serve values from the old path and make you think the fix did not land. Always config:clear before concluding anything about config resolution.

Publish tags are inconsistent across packages. The provider may register --tag=tomato-sauce-config, --tag=config, or no tag at all. Check the service provider's publishes() call rather than guessing; a wrong tag silently publishes nothing and exits 0.

No prior assessment exists. This is the first review of this package. The evidence base is one patch release, so treat any API guidance here as provisional — the README and the service provider are the ground truth, not this document.

Debugging config resolution. When a value is unexpectedly null, check in this order: (1) is the config file actually in config/? (2) does the key path match the vendor file exactly, including nesting? (3) is config cached? (4) is the service provider registered (auto-discovery enabled in composer.json)? (5) is an .env override winning over the published default?

Extension points. The reliable extension point at this version is the published config plus your own wrapper class. Avoid subclassing package internals or binding over its container entries until the package stabilizes — internals are the most likely thing to move in 1.1.x.

Version pinning is not optional here. A single-contributor patch release that changes config path resolution is a reminder that ^1.0 is loose enough to surprise you. Pin 1.0.2 exactly if this package is on a critical path, and review the changelog before each bump.