Product Decisions This Supports
- Upgrade timing and sequencing for v3.0.0. This is a major release whose only documented change is that it requires "Url highlight v3." For a PM, that reads as one decision: the package's URL-highlighting capability is now pinned to a newer upstream dependency, and that dependency bump — not the package itself — is the migration work. Treat it as a compatibility gate rather than a feature release.
- Roadmap placement of any URL/link rendering surface. If URL highlighting appears in user-facing content (comments, messages, descriptions, changelogs, activity feeds), this package is the thing that determines how links render, truncate, and behave. Any planned work on rich text, link previews, or content safety should be sequenced against this upgrade.
- Build vs. buy for link detection and rendering. Highlighting URLs correctly is deceptively fiddly (punctuation adjacency, trailing periods, parentheses, unicode, HTML escaping, XSS safety). This package exists to avoid owning that logic in-house — a decision to keep buying rather than maintain a regex.
- Dependency hygiene as a product concern. A required major-version bump upstream is a signal that the dependency tree is moving. This informs planning for security patching cadence and PHP/Laravel version support windows.
- Not supported by this release: no new end-user features, no deprecations announced beyond the implicit API surface of "Url highlight v3," and no performance or roadmap claims. Do not build a launch narrative around v3.0.0.
When to Consider This Package
Adopt when:
- You render user-supplied or CMS content that contains bare URLs and need them linkified consistently and safely.
- You want that behavior encapsulated in a maintained dependency instead of an in-house regex, and you are willing to track its major versions.
- Your application can absorb a required upstream major bump — i.e., you can upgrade the "Url highlight v3" dependency in the same change window and re-run rendering tests.
Look elsewhere (or defer) when:
- You are mid-freeze, mid-release, or on a Laravel/PHP version that the new required dependency does not support. A required major bump is the classic cause of a transitive conflict; check compatibility before committing.
- You need rich link previews, unfurling, or metadata extraction — highlighting is a narrower concern than preview generation.
- You already have a hardened, tested linkification path (e.g., a markdown renderer or a sanitizer that handles this). Adding a second implementation creates divergent rendering across surfaces.
- The package's release notes are your only source of truth about the change. This changelog is a single line; if you cannot inspect the diff or the upstream dependency's own breaking changes, that is a reason to investigate first, not to ship.
Adoption criteria to confirm before upgrading: the upstream "Url highlight v3" release notes and breaking changes, minimum PHP/Laravel versions, whether the package's public API changed, and whether your rendered-output tests (snapshot or HTML assertions) still pass.
How to Pitch It (Stakeholders)
For executives: A dependency we use for rendering links in user content shipped a new major version. The change is not a feature — it now requires a newer version of its underlying URL-highlighting library. That means the work is a compatibility upgrade, not a capability gain, and it should be scheduled as maintenance with a test pass, not announced as a release. Risk is low if we verify compatibility first; the cost of skipping the check is a transitive dependency conflict or subtly different link rendering in production.
For engineering: v3.0.0 requires "Url highlight v3." Confirm the upstream breaking changes, bump both together in one PR, and rely on output-level tests (linkified HTML, trailing punctuation, parentheses, escaping) rather than unit tests alone, since rendering behavior is the thing that can silently shift. Flag any Laravel/PHP support matrix changes. The changelog is one line — read the diff before merging.
Recommendation: Investigate and schedule; do not treat as a feature. Hold the upgrade until upstream breaking changes are confirmed and rendering tests are in place.