Text Wrap Laravel Package

Product Decisions This Supports

• Build vs. buy — the answer is "build." The delivered value here is presentation: wrapping long text so it doesn't truncate in Laravel Nova index/detail views. On Nova 3+, that's a displayUsing() callback or a small custom field generated with php artisan nova:field. Adding an archived dependency to solve a CSS-level concern is a worse trade than owning ~30 lines of code.
• Resolve the description/reality mismatch before scoping anything. The package description pitches a zero-dependency, multibyte-safe PHP string-wrapping utility for console output, plain-text email, and PDFs. The code is a Laravel Nova field extension — a Text subclass, a service provider, and a compiled Vue asset. These are different products with different buyers. A PM who scopes off the description will budget the wrong work. Verify against src/ and composer.json before any ticket is written.
• Admin UX prioritization. The package's existence is a weak but real signal that operators care about long-text legibility in admin tables — notes, addresses, descriptions, error payloads. That earns a line in an internal-tooling polish backlog, not a roadmap theme or a funded initiative.
• Legacy platform triage. Actionable only if we're still on Nova 1.x/2.x with no upgrade inside 12–18 months. In that narrow window it's a candidate stopgap while the upgrade is planned; it is never a candidate for greenfield work.
• Dependency-policy calibration. Archived, last release 2018-08-31, 10 stars, 0 dependents, composite score 0.025, opportunity 29.64. This is a clean worked example for a "do we accept abandoned dependencies?" rule. The low opportunity score reflects the actual market: the niche is tiny and already served, so nobody is waiting on this.
• Reference implementation, not a dependency. If an engineer needs to see how a Nova field package is structured — field class, provider, Nova::script()/Nova::style() registration — reading the source is cheaper and safer than installing it.
• Framing for "our admin tables are unreadable." That's a design problem: column selection, truncation length, detail-view-first navigation, theme CSS. Not a package-selection problem. Buying here treats the symptom.

When to Consider This Package

Consider it only if all of the following hold:

• We are on Laravel Nova 1.x or 2.x with no realistic upgrade path inside 12–18 months.
• We specifically need wrapped (not truncated) rendering in Nova index or detail views, and genuinely have no capacity to write the field ourselves.
• We accept that we are vendoring unmaintained code — no security patches, no PHP 8 or Nova 3+ compatibility, no upstream support — and fork it into our own namespace as first-party code we now own.

Look elsewhere — or build — if any of these are true:

• Nova 3, 4, or 5. The package predates them. Field-lifecycle and asset-pipeline drift make incompatibility likely, and the failure mode is a blank or broken resource screen, not a clean exception.
• PHP 8.x. Seven years without a release means no compat or deprecation work has landed; Composer resolution will likely fail outright against a modern laravel/nova constraint.
• Anything beyond static display. Editing affordances, copy-to-clipboard, expand/collapse, HTML sanitization, and per-resource configuration are all out of scope — the field does one thing.
• The requirement is actually a string utility. For console output, plain-text email, PDFs, or fixed-width reports, use PHP's built-in wrapping functions or a maintained text library. Do not install a Nova field for this; the mismatch will burn a sprint.
• Dependency policy requires a maintained upstream, a security contact, or a support SLA. It fails all three.
• The real diagnosis is UX. If the complaint is "the index tables are unreadable," a package won't fix it — column strategy and a theme override will.

Sequencing if we pursue the behavior: run a ≤1-day spike with stock Text/Textarea plus a CSS override in our Nova theme. If that passes, close the ticket. If it fails, build the field in-repo via php artisan nova:field (1–2 engineer-days including tests) and register it in the shared Nova field kit. Contingency adoption — only if leadership mandates reuse — means forking into a Composer path repository, rebuilding the Vue component against our installed Nova toolchain, grepping the JS for v-html/innerHTML (stored-XSS risk inside the admin panel), and adding a CI smoke test.

How to Pitch It (Stakeholders)

To executives: This is a 10-star, archived Laravel Nova field from 2018 with zero dependents and no releases in seven years. Its function is to render long text with wrapping in admin screens — a CSS concern. It is not a strategic asset, not a market signal, and not a build-vs-buy decision worth escalating. We should not add it to our dependency surface: we'd inherit a 2018 Vue 2 component on a paid, closed-source host framework, with no upstream, no security contact, and no community of scale. If we need the behavior, an engineer reproduces it in under a day inside our own codebase, where we control the upgrade path and security posture. Recommendation: decline adoption; log the underlying UX need — long-text legibility in admin tables — in the internal-tooling backlog.

To engineering: If you're on Nova 1/2 and want it now, fork it, pin the commit, and own it — don't require it from Packagist, or a future composer update will pull the abandoned release again. If you're on Nova 3+, skip it and use Text::make('field')->displayUsing(...) or a small in-repo field. Either path is well under a sprint day, and the ongoing cost of the fork exceeds the cost of writing it fresh. Watch the silent-failure mode: asset-pipeline drift usually surfaces as a blank or unstyled cell, not an error, so cover it with a smoke test.

Decision: No-go on adoption. Go on a small in-house field — or a Nova theme CSS override — if the UX need is confirmed by support-ticket or operator feedback.