Readmore Laravel Package

Product Decisions This Supports

• Admin UX polish on long-text fields. This is a Nova field that renders long text (descriptions, notes, log excerpts, JSON payloads, support-ticket bodies) in a collapsed/expandable "read more" form. The decision it supports is small but recurring: do we keep stuffing long values into standard Nova text fields and let index/detail views become unreadable, or do we standardise on a truncate-and-expand field for those columns?
• Nova upgrade roadmap (the real decision in 2.2.0). Nova 5 support (laravel/nova: ^4.0 || ^5.0) is the only material change in this release and it directly de-risks our Nova 5 migration. It means any Nova 5 upgrade plan can keep this field in place rather than blocking on a fork, a replacement, or a custom field build.
• PHP version constraint as a planning input. On PHP 8.0 only Nova 4 resolves; PHP 8.1+ resolves Nova 4 or 5. If we are still on PHP 8.0 anywhere, this field effectively pins that environment to Nova 4 — worth surfacing in the platform-upgrade sequencing conversation, not as a blocker but as a dependency to sequence.
• Build vs buy: buy (or rather, don't build). The scope is a single presentational Nova field. A custom in-house field would cost engineering time for zero differentiation, plus ongoing Nova-version maintenance. Consuming a maintained package is the correct default; the only real question is whether the maintenance risk is acceptable for a non-critical admin surface.
• Use cases to scope it to. Index and detail views where a long value is only occasionally needed in full: audit/activity logs, exception messages, customer notes, marketing copy previews, imported CSV rows. It is not a fit for fields users must always read in full (legal terms requiring acknowledgement, primary content editing).
• Low blast radius means low ceremony. This is an internal admin-panel dependency, not customer-facing runtime code. It does not need an ADR, a spike, or a security review beyond normal supply-chain hygiene — a ticket and a compatibility check is proportionate.

When to Consider This Package

• Consider it when the team runs Laravel Nova and the admin UI has one or more long-text columns that currently bloat index rows or push detail layouts around, and we want that fixed without a custom field.
• Consider it specifically now if a Nova 5 upgrade is on the roadmap. 2.2.0 is the release that makes this package a non-issue in that migration — the field code and compiled bundle are unchanged between Nova 4 and 5, and per the Nova 5 upgrade guide there are no relevant breaking changes for a field of this shape.
• Upgrade cost is effectively zero. "Nothing to do to upgrade" per UPGRADE.md; it is a constraint-widening release, not a behavioural one. Treat 2.2.0 as a routine composer update.
• Look elsewhere (or build in-house) when:
  • The environment is pinned to PHP 8.0 and Nova 5 is required — the dependency tree will not resolve; fix PHP first.
  • The need is rich text rendering (markdown, sanitised HTML, syntax highlighting, diffing). This is a truncate-and-expand field, not a renderer.
  • The content is regulated, customer-facing, or must be verifiably displayed in full — do not put compliance-relevant copy behind an expand toggle.
  • The team is not on Nova at all (Livewire/Filament/Blade-only admin) — the package is irrelevant.
  • Single-maintainer risk is unacceptable for the surface. Mitigation here is proportionate: pin the version, keep it out of critical paths, and be ready to replace with a ~half-day custom field if it goes unmaintained.
• Supply-chain check before adoption: confirm Nova licence tier covers the target version, confirm CI matrix coverage (2.2.0 adds Nova 4 and 5 to the tests matrix, which is a positive maintenance signal), and note the package now also requires orchestra/testbench ^8.30 || ^9.8 in dev — a dev-only constraint that should not affect consumers.

How to Pitch It (Stakeholders)

For executives (one paragraph): We use a small, free, open-source add-on for our Laravel Nova admin panel that collapses long text fields behind a "read more" toggle, keeping internal screens readable. Its new release (2.2.0) adds support for the next major version of Nova. That matters because it removes a potential blocker from our planned Nova upgrade — we can move to Nova 5 without rebuilding or replacing this component. There is no cost, no migration work on our side, and no customer-facing impact; it is an internal tooling dependency only.

For engineering (bullets):

• 2.2.0 widens laravel/nova to ^4.0 || ^5.0. Field code and compiled assets are unchanged — no rewrite, no API changes, no deprecations.
• Constraint interaction to note: PHP 8.0 resolves Nova 4 only; PHP 8.1+ resolves Nova 4 or 5. Our PHP floor therefore gates the Nova 5 path more than this package does.
• Dev-only churn: orchestra/testbench ^8.30 || ^9.8, CI matrix now covers both Nova majors. Good maintenance signal; no consumer impact.
• Upgrade action: bump the constraint, run the suite, ship. See UPGRADE.md § "Upgrading to 2.2".
• Residual risk: single-maintainer package on a non-critical admin surface. Mitigate with a pinned version and the standing fallback of a small in-house field if maintenance lapses — this is not a component we should be architecturally dependent on.