- Is mrgoodbytes8667/string-mask-bundle a Laravel package?
- No. Despite being listed on a Laravel/PHP package index, it is a Symfony bundle with a Twig extension. It ships no service provider, no facade, and no Laravel auto-discovery, and Laravel renders with Blade rather than Twig. Treat the Twig filter surface as unusable inside a Laravel application.
- How do I install mrgoodbytes8667/string-mask-bundle in a Laravel app?
- Composer installation is mechanically trivial, but that is the least of the problem. Pulling twig/twig and Symfony bundle wiring into a Blade app adds transitive symfony/* constraints that can collide with the Illuminate stack and block future framework upgrades. Run composer require --dry-run on a scratch branch first, and expect no Laravel integration wiring afterward.
- Which Laravel versions does this string mask bundle support?
- The evaluation does not confirm a supported Laravel version range because this is not a Laravel package at all. Its constraints target Symfony and Twig, and the last release was 2024-08-01, leaving roughly a year of drift from current PHP and Symfony releases. Check composer.json for permissive caret ranges versus pinned versions before assuming compatibility with your Illuminate version.
- Can I use Twig filters in Laravel Blade templates?
- No. Twig filters and functions have no effect in Blade templates. Using this package in Laravel would mean running Twig alongside Blade purely to reach a string masking helper, which is a disproportionate architectural cost for the benefit.
- What license does mrgoodbytes8667/string-mask-bundle use, and is it safe for commercial use?
- The repository reports NOASSERTION, which means the actual terms are unverified until someone reads the LICENSE file. Do not ship code that touches PII or masked identifiers before legal review. For a Laravel team this is a procurement gate, not a footnote.
- Does Laravel have a built-in alternative to this string masking bundle?
- Yes. Laravel 9 and later ship Str::mask($value, '*', 3, 4) plus the fluent Str::of($value)->mask() form, covering the large majority of phone, ID, and card masking needs with zero added dependency risk. For per-field strategies, wrap that in a small Masker service instead of adopting a bundle.
- How does this package handle UTF-8, null, and short strings when masking?
- The evaluation does not validate this, and it matters because masking is a data-exposure control. Naive implementations break on multibyte and UTF-8 input, null or empty strings, and short values where the mask reveals the entire original. Confirm a real test suite exists before trusting it for anything security-adjacent.
- Is the masking logic usable without Twig, for example from a service class?
- Unverified. The masking behavior is only confirmed to be reachable through the Twig extension, and whether the author kept the primitive in a framework-agnostic class is unknown until the source is read. If you adopt any part of it, isolate that core class behind your own interface.
- How should I test string masking in my Laravel application?
- Do not test through a Twig filter in a Laravel codebase. Express the behavior you need as an internal contract such as Masker::maskPhone() and Masker::maskCard(), then test that contract with cases covering UTF-8, null, empty, and very short inputs. The tests then stay valid whether the implementation is this package, a fork, or Str::mask().
- Is this package actively maintained and safe to use in production?
- Based on the assessment, no. It has zero stars, zero dependents, a single maintainer, a single release cadence, and no disclosed security policy or vulnerability reporting channel. For Laravel teams the recommendation is to reimplement or vendor a small, license-cleared helper rather than carry a stale dependency.