Tomato Timer Laravel Package

Technical Evaluation

Context: tomatophp/tomato-timer v1.0.1 is an early-stage package in the TomatoPHP ecosystem (a large family of Filament plugins maintained primarily by @3x1io). The v1.0.0 → v1.0.1 delta is limited to an install script and README update — no runtime code changes, no breaking changes, no deprecations. Treat this release as a documentation/onboarding fix rather than a functional signal.

Architecture fit

• Presumed fit: a Filament panel widget/plugin providing a timer (Pomodoro-style) surfaced to admin-panel users. That makes it a presentation-layer dependency, not a core domain dependency — favorable for risk containment.
• It sits on top of the Filament + Livewire + Laravel stack. Fit is high if your admin surface is already Filament; near-zero if you are on Blade/Inertia with a custom UI.
• Because timers are inherently client-side, expect a JS asset (Alpine.js or a compiled bundle) shipped via a service provider. That introduces an asset-publishing step into your deploy pipeline — a real architectural consideration, not just a composer require.

Integration feasibility

• Low effort in a greenfield Filament app: composer require, publish assets/config, register the plugin on the panel. The v1.0.1 install-script fix suggests the maintainer is actively smoothing exactly this path, which is a positive onboarding signal.
• Non-trivial in an existing app with custom asset pipelines (Vite configuration, CSP headers, CDN-offloaded assets), or where you cannot add a panel plugin without touching config/filament.php.
• The 1.0.x version line implies API stability is claimed but not demonstrated; there is no evidence of a deprecation policy.

Technical risk

• Bus factor / vendor risk (high): single-maintainer ecosystem package. Continuity depends on one person's availability.
• Version-coupling risk (medium-high): TomatoPHP plugins have historically tracked Filament major versions closely. A Filament v4 upgrade could strand this package until the maintainer catches up. Pin your Filament constraint and test upgrades in a branch.
• Abandonment risk (medium): v1.0.1 changelog is cosmetic; that is consistent with an early, low-traffic package, but it also means limited field validation.
• Functional risk (low): a timer widget failing degrades UX, not business logic — unless timer state is persisted and drives billing, SLA, or time-tracking records, in which case the risk profile changes materially.
• Supply-chain risk (low-medium): package install scripts that touch the filesystem should be reviewed before execution in CI.

Key questions to resolve before adopting

1. What are the declared Laravel, PHP, and Filament version constraints, and is Filament v4 supported?
2. Is timer state ephemeral (browser) or persisted server-side? If persisted — which tables, and are migrations reversible?
3. Does the install script modify application files outside vendor/ and public/? Can it be run non-interactively in CI?
4. What test coverage exists, and does CI run against a matrix of Laravel/Filament versions?
5. License and commercial support terms; is there a paid support tier via the TomatoPHP commercial offering?
6. Any Livewire polling / broadcast requirements that would add load to the app servers?

Integration Approach

Stack fit

• Qualifies cleanly for a Laravel + Filament admin panel on PHP 8.1+. Disqualifies for non-Filament front ends and for teams standardizing on Livewire-free stacks.
• Natural placement: internal tooling, ops dashboards, or a productivity module inside an existing back-office panel. Not a candidate for a customer-facing product surface.

Migration path

• This is a net-new adoption, not a migration. There is no incumbent to displace, so the path is: spike in a scratch branch → validate the panel renders and the timer behaves → decide go/no-go → promote to a shared internal package.
• Because the package is a leaf dependency, removal is equally cheap. Design the integration so nothing outside the panel imports its classes directly — no domain code should reference the timer's models or service classes.

Compatibility

• Pin explicitly: composer require tomatophp/tomato-timer:^1.0 plus a locked Filament constraint. Do not allow a floating Filament range in the same lockfile.
• Verify asset publication against your Vite/build setup before committing. If your pipeline does not run vendor:publish, add the step to the deploy runbook.
• Confirm the package does not register global Livewire components that collide with existing names.

Sequencing

1. Week 1 — spike. Install in a throwaway branch; confirm Filament version compatibility and asset publishing. Effort: ~1 engineer-day.
2. Week 1 — risk review. Read the install script and service provider; confirm migrations are reversible and no global side effects. Effort: ~0.5 day.
3. Week 2 — pilot. Enable on a single internal panel for a small user group; instrument for JS errors and polling load.
4. Week 2–3 — decide. Fork-and-vendor if the maintainer is unresponsive on the version-support question; otherwise adopt upstream.
5. Defer any persisted time-tracking use case until the data model is confirmed and a retention/audit decision is made.

Operational Impact

Maintenance

• Low ongoing code maintenance (leaf dependency, cosmetic release cadence). The real maintenance cost is upgrade chasing: expect to re-validate on each Filament major release.
• Budget roughly 1–2 engineer-days per Filament major upgrade cycle, plus a trivial quarterly "is it still maintained?" check.
• Keep a fork-ready posture: vendor the package into a private repository if upstream goes quiet for more than two release cycles of your target Filament version.

Support

• No commercial SLA assumed. Support is GitHub issues on a volunteer basis. For anything business-critical, assume self-support is the default and staff accordingly.
• Document the integration internally (config keys, published assets, how to disable the widget) so an on-call engineer can turn it off without reading the source.

Scaling

• Client-side rendering scales with the browser, not the server — favorable.
• The scaling question is polling. If the widget refreshes state on an interval, N concurrent panel users multiply into background request load. Measure before enabling for a large user base; prefer a purely local timer with no server round-trips.
• No expected database growth unless timer history is persisted; if it is, plan retention from day one.

Failure modes

Blast radius is contained by design: an isolated panel widget can be feature-flagged off without touching business logic. Preserve that property — do not let timer data become a system of record without a deliberate, separately-assessed decision.

Ramp-up

• Engineering: ~0.5 day to read the source and service provider; ~1 day to integrate and validate.
• End users: negligible — the UI is self-explanatory; a one-paragraph note in the internal changelog suffices.
• Operations: ~2 hours to add the publish step and the feature flag to the runbook.

Recommendation: Adopt for internal Filament panels at low commitment (pilot + feature flag), contingent on confirming Filament version support and the ephemeral-vs-persisted state question. Do not adopt as a system of record for time tracking without a follow-up assessment. v1.0.1 itself is a no-op for risk purposes — it slightly improves the onboarding story and signals a maintainer who is still tending the package, which is the most useful information in this release.