Weave Code
Laravel Str Mixins Laravel Package
revolution/laravel-str-mixins
Adds custom macro mixins to Laravel's Str helper, extending it with handy string methods you can call fluently anywhere. A lightweight way to register reusable string macros across your app without repeating helper code.
At a glance
Frequently asked questions about Laravel Str Mixins
- What does revolution/laravel-str-mixins do?
- It is a small Laravel package that registers additional macros on Illuminate\Support\Str, so extra string formatting and inspection helpers become available as Str:: method calls anywhere you already use the Str helper. Macros are registered automatically through package discovery, so there is no service provider edit, config file, or manual setup. It adds no container bindings, events, persistence, or runtime dependencies beyond Illuminate\Support.
- How do I install revolution/laravel-str-mixins, and do I need to register a service provider?
- Run composer require revolution/laravel-str-mixins and the macros are registered automatically via Laravel package discovery. You do not need to edit config/app.php, publish configuration, run migrations, or set environment variables. On older Laravel skeletons without package discovery, register the package service provider manually once.
- Which Laravel versions does this package support?
- The only version-sensitive coupling is the package's illuminate/support constraint plus Str remaining macroable, so check that constraint against your pinned Laravel version before installing. There is no other framework-specific runtime code, and it behaves the same in monoliths, modular monoliths, and package-style codebases. Because macros can be silently bypassed if Laravel later adds a same-named native method, revalidate on each Laravel minor bump and assert on helper output in tests.
- Can I use these Str macros in Blade templates and fluent chains?
- Yes. Once installed, the macros are available anywhere Str:: is used, including Blade views, controllers, models, and Str::of() chains. They are implemented as chainable helpers that integrate with the existing Str methods rather than a parallel API, so they slot into pipelines you already write.
- Can I add my own macros alongside the packaged ones?
- You can call Str::macro() with your own closures in a service provider boot method and they will sit alongside the packaged macros. Keep a single registration point and a naming convention so it is obvious which macros your application defines. Be aware that registering the same name twice silently overwrites the earlier implementation.
- What happens if a macro name collides with another package or a future native Str method?
- Macroable::macro() overwrites without throwing, so a collision with another package or your own bootstrapping code produces last-writer-wins behavior instead of an error. The inverse also applies: if Laravel adds a native method with the same name, the macro is silently bypassed and its semantics can shift on a minor upgrade with no failure. Audit your dependency graph and bootstrap for the exact names you use, and cover the outputs in tests.
- Does it work with PHPStan, Larastan, and IDE autocompletion?
- Not out of the box. Static analysers and editors cannot resolve macro methods on Str without @method annotations, which produces undefined-method errors and IDE warnings that teams often misattribute to the package. Add @method stubs for the helpers you actually use, and treat maintaining those stubs as an accepted cost of the dependency.
- Is it safe for production, and what are the maintenance risks?
- The blast radius is low because the worst-case failure is a misformatted string, not a data or availability problem. The real risks are governance-level: silent name collisions, silent bypass when Laravel ships a same-named method, static-analysis blind spots, single-maintainer concentration, and no downstream canaries. Pin the version, assert on helper output in tests, and assign a named owner for revalidation at each Laravel minor release.
- Is a third-party dependency worth it for a dozen string helpers, or should I copy the code?
- The package is MIT licensed and small enough that vendoring the closures into an internal App\Support\Str class is a realistic exit option with no legal friction. Whether that is cheaper depends on how many call sites each helper actually retires in your own codebase; if the boilerplate is not genuinely repetitive across teams, do not take the dependency. The honest decision is a count of calls replaced versus the ongoing cost of stubs, collision audits, and upgrade checks.
- How do I remove revolution/laravel-str-mixins if I stop using it?
- Removal is a one-line Composer change plus inlining whatever helpers are still in use. There is no data migration, no consumer-facing API, and no residual cleanup beyond the call sites themselves. Adopt the macros at new or touched call sites only rather than refactoring working code, so removal stays cheap.
Weaver
How can I help you explore Laravel packages today?