Linkify Laravel Package

Product Decisions This Supports

• Auto-linking plain-text URLs and emails across content surfaces — comments, support tickets, profile bios, DMs, activity feeds, notification bodies, changelog entries, CRM notes, and help-center excerpts. This is a low-cost, high-visibility UX polish item: users paste links constantly and expect them to be clickable without a rich-text editor.
• Build-vs-buy scoped correctly. The honest framing is "require a 2017 single-purpose regex utility vs. write/vendor ~50–100 lines of owned code." This is a pattern decision (auto-linking is table stakes), not a platform or vendor bet. Do not spend roadmap energy standardizing on it; spend a day owning the behavior.
• Trust-and-safety policy decisions that a PM must actually make, because linkifying untrusted text is XSS- and phishing-adjacent:
  • Scheme allow-list (http, https, mailto only — no javascript:, data:, file:).
  • Attribute policy: rel="nofollow noopener noreferrer", configurable target="_blank".
  • Which surfaces are too high-risk to linkify at all (billing emails, admin panels, transactional messages).
  • Whether public surfaces should linkify emails at all (spam harvesting) or leave them as plain text.
• Roadmap placement: linkification is an enabler inside an existing content/engagement epic, not a standalone initiative. It should ship with the feature that needs it and carry no dedicated budget line.
• Dependency-hygiene decisions: last release 2017-08-17, 112 stars, zero dependents, no commit cadence. That combination supports a defensible "adopt the behavior, not the dependency" call — vendor a fork under an internal namespace or reuse an existing framework text helper, keeping the runtime dependency graph clean and the security-response burden internal.
• Sequencing decisions: escape-then-linkify order must be defined by the app, not the library (it escapes nothing). This forces a decision on where text rendering lives — a single TextLinkifier service rather than scattered regex helpers, Blade snippets, and overlapping libraries.

When to Consider This Package

Consider it (as reference, prototype, or vendored code) when:

• You have a legacy or small PHP codebase on an older PHP version where the 2017 release still installs cleanly, and you need auto-linking with minimal effort.
• You want a permissive (MIT), dependency-free, single-responsibility implementation to read, fork, or vendor — it's small enough to own outright.
• The surface is low-risk internal content (admin notes, internal wiki, staff tooling) where escaping and attribute policy are already enforced by the renderer.
• You need a baseline to validate a hand-rolled regex, particularly for email matching and trailing-punctuation edge cases, which are easy to get subtly wrong.
• You want per-call customization (custom attr, a callback that replaces the generated anchor) to add icons, tracking parameters, or wrapper markup without writing the matching logic yourself.

Look elsewhere or build internally when:

• You are on Laravel + PHP 8.1/8.2/8.3. A 2017 regex package untested against current PHP is a maintenance liability, and there is no service provider, facade, config, or Blade directive — you'd write the integration layer anyway.
• The content is user-supplied and untrusted. You need guaranteed escape-then-linkify ordering, strict scheme allow-listing, rel/target policy, and lookalike/IDN awareness. Do not assume an unmaintained package handles this; the library deliberately escapes nothing.
• You need maintained alternatives with an active security response: framework utilities (e.g. cakephp/utility text helpers), a maintained linkify fork, or a Markdown/autolink pipeline if you already render Markdown.
• You need framework integration, Unicode/IDN-aware matching, email obfuscation, or URL truncation — the package is intentionally bare.
• Linkification would sit alongside sanitization, truncation, and mention/hashtag parsing — that should be one coherent text-rendering service, not four overlapping libraries.

Adoption gate before committing: confirm it installs under your Composer constraints, run its test suite on your target PHP, and diff its output against your escaping pipeline on representative payloads (URLs with trailing punctuation, parenthesized URLs, Unicode text, HTML entities, emails, and javascript:-style attacks). If either check is shaky, vendor the class into your own namespace and own it.

How to Pitch It (Stakeholders)

To executives: This is a tiny, MIT-licensed utility that turns bare URLs and email addresses in plain text into clickable links — a cheap UX polish item for our community, messaging, and support surfaces. There is no license cost and no strategic platform implication. The only real consideration is maintenance hygiene: the last release was 2017, has almost no downstream users, and has no security response. My recommendation is to adopt the capability, not the dependency — reuse an existing framework helper or vendor a small internal version we control. We get the user-facing benefit with no long-term support or supply-chain exposure, and the work fits inside an existing content epic at roughly a day of effort.

To engineering: One class, regex-based, zero runtime dependencies, permissive license, and no Laravel integration whatsoever — no provider, config, or Blade directive. Two concerns matter: it predates current PHP versions, and linkifying untrusted text is an XSS-adjacent operation (it also escapes nothing, so escaping order is on us). Recommendation: do not add it as a direct Composer dependency. Either use a maintained framework utility already in the stack, or fork/vendor the implementation behind an app-owned Linkifier::process(string $text): string service that (1) escapes before linking, (2) allow-lists http/https/mailto, (3) applies rel="nofollow noopener noreferrer" and a configurable target, and (4) has contract tests for trailing punctuation, parentheses, Unicode, HTML entities, and malicious payloads. Bind it as a singleton so policy is centralized, keep it out of hot paths with input size limits, roll it out behind a feature flag, and treat "keep vs. fork vs. replace" as a decision gate after a time-boxed spike. No migration, no ops impact.

One-line summary: Great behavior, stale package — take the idea, own the code, and keep the dependency graph clean.