String Mask Bundle Laravel Package

Product Decisions This Supports

• Feature decisions around PII exposure in internal tooling. Masking (j***@example.com, **** **** **** 4242, (***) ***-1234) is the cheapest way to let support, finance, and ops staff do their jobs without seeing raw customer data. This package's real contribution is a taxonomy of mask types you can lift into your own spec.
• Compliance roadmap scoping. If GDPR/CCPA/PCI-DSS/HIPAA obligations are on the roadmap, "data minimization for non-privileged viewers" is a discrete workstream. Masking is the presentation-layer slice of it — distinct from, and much cheaper than, field-level encryption, tokenization, or a full data-classification program.
• Build vs. buy. This is a buy candidate only on paper. The surface area is small (a masker class plus a template filter), it targets Symfony + Twig, not Laravel/Blade, and the repo shows 0 stars, 0 dependents, and two releases. For most teams the honest answer is build — a Masker service with maskEmail()/maskPhone()/maskCard() and a Blade directive is roughly 1–2 engineer-days, fully owned, no license ambiguity.
• Use cases worth scoping regardless of the package: support/admin dashboards, audit and application logs, transactional email templates, CSV/report exports, staging/demo seed data, and QA fixtures.
• A framework-mismatch decision. Because this is a Symfony bundle, in a Laravel codebase it would only be reachable by pulling in Twig alongside Blade and wiring the bundle manually — a two-templating-engine tax for one string filter. That alone usually kills the adoption case. v1.1.0 does not change this; it narrows the Symfony/PHP window without adding a Laravel path.

When to Consider This Package

Adopt only when all of these hold:

• You are on Symfony 6.4 or 7.x with Twig as the template layer — not Laravel/Blade. (v1.1.0 dropped Symfony ≤6.3 and PHP ≤8.1; the viable floor is now Symfony 6.4+ on PHP 8.2+, so this is no longer a "Symfony 5/6/7" wide-net option, and it is a hard blocker if you still run PHP 8.1 anywhere in the fleet.)
• Masking is strictly a presentation concern; you are not trying to protect data at rest or in transit.
• Your legal team accepts a NOASSERTION license — v1.1.0 does not change this, and it remains a hard blocker in most enterprises, since the license terms are not machine- or counsel-verifiable from the manifest.
• You accept a single-maintainer, zero-adopter dependency for a function you could own outright. The v1.1.0 "fix tests" and rector/php-cs-fixer cleanup are a mild positive maintenance signal, but two releases and no adopters is still not a track record.

Look elsewhere or build in-house when:

• You are on Laravel, Blade, or a JS/React frontend — write the masker yourself.
• You are pinned to PHP 8.0/8.1 or Symfony 5.x/6.0–6.3. v1.1.0 will not install there, so upgrading the package means upgrading the runtime first — a platform project, not a feature decision.
• You need masking before persistence (write-path redaction), format-preserving masking for analytics, or column-level masking in the warehouse (do it in the DB/BI layer instead).
• You need unmask-with-audit — privileged reveal with a logged reason and actor. That's an access-control feature, not a string filter, and no masking library gives it to you.
• You need a security policy, disclosure process, or SLA from the maintainer. CI tests existing is not the same thing; none of the above are evidenced.
• Procurement requires license clarity. NOASSERTION means "unknown," and unknown is a stop sign.

How to Pitch It (Stakeholders)

To executives (risk + cost): "We need display-layer masking so support and ops staff can work without seeing full card numbers, emails, and phone numbers. There is an off-the-shelf Symfony package that does this. The new v1.1.0 release is maintenance-only — code cleanup and a raised platform floor (Symfony 6.4+, PHP 8.2+) — no new masking capability, and still no license clarity and no downstream users. That's a supply-chain and legal risk plus a forced runtime upgrade for a feature worth about two engineer-days. Recommendation: build a small internal utility, adopt the package's mask-type taxonomy as our spec, and revisit third-party adoption only if the requirement grows into tokenization or field-level encryption, where buying genuinely beats building."

To engineering (scope): "Don't take the dependency, and don't read v1.1.0 as momentum — it's rector/php-cs-fixer cleanup plus dropping Symfony ≤6.3 and PHP ≤8.1, with zero feature surface added and still no Blade story. Copy the concept instead: a Masker service with email/phone/card/name strategies, exposed as a Blade directive and applied at the rendering layer. Keep it config-driven by field type and role so we can widen masking later without touching call sites. Exclude masked fields from logs and exports by default, not by exception. Note that the package's PHP 8.2+/Symfony 6.4+ floor is worth mirroring in our own spec only if our fleet is already there — check before writing it into an ADR."

Bottom line: v1.1.0 is a maintenance release — a narrower compatibility window, a modest quality signal, and no change to the fundamentals. This package remains a specification, not a dependency: score 0, opportunity ~18, and the framework mismatch keeps it firmly in the "reimplement in a day" bucket for a Laravel shop.