Tc Lib Unicode Laravel Package

Product Decisions This Supports

• Internationalization (i18n) readiness. Informs roadmap decisions on shipping non-Latin interfaces, right-to-left layouts, and locale-aware sorting/search. This package supplies low-level Unicode primitives (normalization, case mapping, character classification) that product features depend on, but it is infrastructure — not a user-facing capability.
• User-generated content handling. Supports decisions about how names, addresses, hashtags, slugs, and search terms are normalized, compared, deduplicated, and safely truncated (grapheme-aware, so emoji and combining marks don't break mid-character).
• Document and PDF generation. If the product generates invoices, reports, tickets, or labels via TCPDF, this is effectively the Unicode layer underneath that feature. Choosing it is largely a consequence of an existing PDF stack decision rather than a standalone one.
• Build vs. buy for Unicode correctness. The real decision is "do we maintain our own Unicode tables and edge-case handling, or depend on a library?" Unicode data changes with every standard revision; in-house tables are a recurring maintenance tax with a long tail of correctness bugs. Buying (adopting OSS) the primitives and building product behavior on top is the defensible default.
• Compliance and accessibility posture. Correct casing, normalization, and rendering for global users touches WCAG-adjacent quality and regional market entry. This package can support those goals but does not by itself deliver them.
• What it does not decide: no Laravel service provider, facade, config, migrations, or Eloquent integration. Do not scope it as a "Laravel package" in planning — budget it as a Composer infrastructure dependency with an internal adapter.

When to Consider This Package

Consider adoption when:

• You are already on the tecnickcom stack (notably TCPDF), where this is likely a transitive dependency — marginal cost is near zero and the license/version review is the only gate.
• You need Unicode primitives in an environment where ext-intl is unavailable or cannot be enabled (shared hosting, constrained containers, legacy PHP targets).
• The surface area you need is narrow and stable — normalization, case folding, character property checks — and you are willing to wrap it behind your own interface so it never leaks into domain code.
• Legal has reviewed the license. NOASSERTION is a hard gate, not a formality — treat it as unknown until confirmed, and check copyleft obligations before any distribution or SaaS packaging decision.
• You have verified provenance: the repository link is unavailable in this listing, stars are low (12), and the release metadata shows a future-dated release (2026-10-10). Confirm Packagist ownership, signed/tagged releases, CI, and a security contact before depending on it.

Look elsewhere when:

• ext-intl is available. Normalizer, Collator, and IntlDateFormatter are faster, maintained by PHP core, and eliminate a dependency. This should be the default first answer.
• You need an actively maintained, security-responsive dependency with community support. symfony/string (with symfony/polyfill-intl-* fallbacks) covers most of the same ground with a mature release cadence and clear licensing.
• You need grapheme segmentation, emoji handling, or bidirectional text at scale — evaluate dedicated libraries rather than assuming coverage.
• The license cannot be resolved, or your organization requires SPDX-identified dependencies in its SBOM.
• You expect Laravel-native ergonomics. None exist here; that integration cost is yours to build.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-cost Unicode utility library that reduces defects in multilingual text handling — names, search, sorting, and PDF output. It is not a strategic bet and not a platform choice; it is a plumbing dependency that is likely already present transitively through our PDF tooling. The recommendation is to adopt it only behind an internal abstraction, with a verified license and a documented fallback to PHP's built-in intl extension. The principal risk is not technical but supply-chain: low adoption, a single maintainer, an unresolved license, and thin release signals. We contain that risk by isolating it, pinning versions, and keeping an exit path that costs days, not quarters.

For engineering:

• Treat it as infrastructure, not a feature dependency. Wrap it in a single UnicodeAdapter-style interface; no direct calls from controllers, models, or Blade.
• Prefer ext-intl where available and use this as the fallback, selected via container binding — this makes the exit cheap.
• Pin the exact version, commit the lockfile, and add a smoke test suite covering normalization, case folding, and grapheme truncation with non-Latin and emoji fixtures.
• Escalate the NOASSERTION license to legal before merge; document the resolved SPDX identifier in the dependency register.
• Add it to the dependency-review watchlist for maintenance and CVE monitoring; re-evaluate at each major PHP upgrade.