Duration Fieldtype Laravel Package

Product Decisions This Supports

• Content modeling: structured duration vs. free text. The core decision this package informs is whether duration values (run time, cook/prep time, course length, media length, contract or SLA windows, onboarding time) should be a dedicated field with predictable storage, or a plain text/number field that editors format by hand. A dedicated fieldtype is only worth it if you expect recurring, machine-readable durations — sorting, filtering, formatting, or display logic downstream.
• Build vs. buy for a narrow field. The scope here is small and single-purpose. The honest comparison is "install a small addon" vs. "spend a day writing an in-house fieldtype." For a small addon, buying is usually cheaper if the storage format and output formatting are documented well enough that you aren't reverse-engineering them.
• Ecosystem commitment. fieldtype naming plus an orchestra/testbench test dependency points to the Statamic addon ecosystem on Laravel. Adopting this is a commitment to that stack and to that addon's release cadence — factor it into platform strategy, not just into a single feature.
• Roadmap expectations. v1.0.1 contains no features, no fixes to product behavior, and no deprecations — only docs, CI, and dependency housekeeping. Treat this as a stable-but-quiet package: fine to depend on for what it does today, but do not sequence roadmap work on the assumption that new capabilities (e.g., richer parsing, timezone awareness, interval math) will arrive on any particular timeline.
• Vendor/maintenance risk assessment. Positive but modest signals: Dependabot is active, CI has been consolidated into reusable org-level workflows, and docs are being actively edited. That suggests a maintained project rather than a dumped one — but the sample is a single patch release.

When to Consider This Package

Consider it when:

• You are building on Statamic/Laravel and need a repeatable way for editors to enter durations.
• Durations are a recurring content concern across entries, not a one-off field on one page.
• You want storage normalized enough to sort, filter, or render durations rather than parsing whatever an editor typed.
• You are comfortable with a young, low-velocity 1.x addon whose current release is a maintenance patch — i.e., you can pin a version and live with it.
• The addon's field-level configuration and output formatting cover your display needs without custom templating work.

Look elsewhere (or build in-house) when:

• You are not on Statamic — the fieldtype abstraction does not transfer, and only the underlying duration-parsing logic would be reusable, if any.
• You need duration arithmetic — summing, subtracting, timezone- or calendar-aware intervals, DST handling. Fieldtypes typically capture and format; they rarely do math for you.
• Your requirement is really a number plus a unit of your choosing; a native number field with a unit suffix may be simpler and cheaper to own.
• You need documented storage-format guarantees before committing (e.g., "is this persisted as seconds, ISO 8601, or a string?"). If the docs don't answer that, that's a blocking gap — the v1.0.1 doc pass trimmed verbosity rather than expanding reference material.
• You require active feature development or vendor support SLAs. Nothing in this release suggests either.

Note for engineering review: the only substantive change is a dev-dependency bump (orchestra/testbench ^10.8 → ^11.2). That is a test-matrix change, not a runtime change, but it typically signals a widening of the supported Laravel/framework version range. Confirm CI is green on your target framework version before upgrading.

How to Pitch It (Stakeholders)

For executives: A small, single-purpose addon that gives editors a proper duration input instead of a free-text box, so durations become reliably sortable and displayable across the site. The v1.0.1 release is housekeeping only — documentation cleanup, CI consolidation, and a test-dependency bump — so it's zero-feature and low-risk. It's an inexpensive convenience purchase, not a platform bet; the main trade-off is that it's a young package with a slow cadence, so we should pin the version and not plan around future features.

For engineering: A Statamic fieldtype for duration entry, now at v1.0.1. Changes since v1.0.0 are non-functional: docs edits, reusable org CI workflows, and a orchestra/testbench bump from ^10.8 to ^11.2 in the dev dependencies. No breaking changes, no deprecations, no API surface changes. Before adoption, verify two things the release notes don't cover: (1) the persisted storage format, since we'll want to query and sort on it, and (2) that CI passes against our Laravel version — the testbench bump implies a widened support matrix but doesn't prove it. If the storage format is undocumented, that's a reason to spike an in-house fieldtype instead.