longman/laravel-lodash
Laravel Lodash brings Lodash-inspired helpers to Laravel and PHP for arrays, objects, and strings: get, set, has, pick, omit, camelCase, and more. A fluent lodash() helper keeps common data manipulation short, chainable, and readable.
Install with Composer and let Laravel's package auto-discovery wire it up:
composer require longman/laravel-lodash
On Laravel 5.5+ no provider registration is needed. On older Laravel or Lumen, register Longman\LaravelLodash\LaravelLodashServiceProvider in config/app.php. There is usually nothing to publish to get running — the package's main payload is a Composer files autoload entry that drops global helper functions into your app.
Where to look first, in this order:
composer.json → autoload.files — this tells you exactly which file(s) get loaded on every request. That file is the real API surface.src/helpers.php (or equivalent) — read it end to end. It is usually a few hundred lines of small functions; that is the whole package value.src/ service provider and config — check whether anything is bound into the container or driven by config/lodash.php. Publish with php artisan vendor:publish --provider="Longman\LaravelLodash\LaravelLodashServiceProvider" if a config file exists.First use case: drop it into a legacy or mid-upgrade app where you keep rewriting the same array/string plumbing — safe nested array access, string case conversion, path/URL juggling, number formatting. Instead of pasting a helpers.php of your own into every project, you get a tested set. Try it in php artisan tinker first:
>>> array_get_safe($nested, 'a.b.c', 'fallback')
The fastest honest evaluation is a 20-minute audit: list every helper the package exposes, then grep your own codebase for code that duplicates it. If the overlap is thin, skip the dependency.
Treat it as an app-level support layer, not a framework extension. The functions are global and stateless — they compose well and are trivially unit-testable:
// tests/Unit/HelpersTest.php
public function test_slug_helper_handles_unicode(): void
{
$this->assertSame('cafe-au-lait', some_helper('Café au Lait'));
}
Wrap before you sprinkle. If you use more than two or three helpers, put a thin facade or App\Support\Helpers class between your code and the package:
final class Helpers
{
public static function slug(string $value): string
{
return \some_package_helper($value);
}
}
This gives you one place to swap the implementation out later — important for a package with this maintenance profile — and keeps the global function calls out of Blade templates where they are hardest to trace.
Blade usage for formatting. Presentation helpers (number/string formatting, truncation, title-casing) are the sweet spot. Prefer passing already-formatted values from a view model or accessor; call global helpers in Blade only for one-liners.
Use it as a migration shim. The most defensible day-to-day pattern is: identify the helpers you actually consume, alias them in a Support class, and mark each one with a @deprecated pointing at the native Laravel replacement (Str::, Arr::, Number::, Str::of()). Then delete the package once the aliases are gone. In practice this is how a package like this should be retired — not by a big-bang removal.
Coexistence guards during rollout. Because these are global functions, you cannot have two definitions. If Laravel or another package already defines the same name, add a guard at the call site while you migrate:
if (! function_exists('some_helper')) {
// package provides it
}
Better: never call the namespaced-ambiguous helper directly from new code at all — go through your wrapper.
Composer-level integration tip. If you only need a handful of functions, you can copy the relevant ones into app/Support/helpers.php, add that file to your own autoload.files, and drop the dependency entirely. Verify the license (MIT here) permits it — it does, with attribution.
Global namespace pollution is the defining risk. Helper functions live in the root namespace. They can collide with:
str(), array_get/data_get, blank(), class_basename, etc., many of which have been added or deprecated across versions),helpers.php.Symptom is a fatal Cannot redeclare ... at boot, before any of your code runs. Diagnose with grep -rn "function <name>" vendor/ app/ and check composer.json autoload.files order — the first file loaded wins, and the loser fatals.
Helpers load before the framework boots. Because they are autoload.files, they are available extremely early — which is occasionally useful and frequently a trap: config(), app(), facades, and translations may not be ready. Never call a container-dependent helper from a service provider's register(), from another package's bootstrap, or from a Composer script. If a helper silently returns a default, suspect an un-booted container rather than a logic bug.
No service container means no mocking. You cannot swap a global function in a test. If you need to stub behaviour (e.g. a clock- or config-dependent helper), wrap it — that is the extension point. There is no interface to bind.
Auto-discovery hides the wiring. If helpers "aren't there", check bootstrap/cache/packages.php and run php artisan package:discover. In Lumen, auto-discovery does not exist at all — manual $app->register() is mandatory, and config() may be unavailable in the way the helper expects.
Run composer dump-autoload after any change to autoload.files. Newly added helper files are not picked up by a plain require; you will chase a phantom "undefined function" for twenty minutes otherwise.
Version pinning matters more than usual here. Low dependent count and a single-maintainer history mean you are effectively the QA. Pin an exact version ("longman/laravel-lodash": "1.x.x" or a commit hash), commit composer.lock, and read the changelog before every bump. Prefer --prefer-dist and audit the diff when the version jumps — helper packages have a habit of renaming functions in minor releases, and a rename is a fatal at boot, not a soft failure.
Deprecation drift is the real long-term cost. A meaningful share of the helpers this package was built to supply now exist natively in Laravel (Str::of() fluent strings, Arr:: accessors, Number:: formatting, Str::slug() with locale support). Audit each helper you use against the current framework version before adopting — you may be adding a dependency to avoid typing something Laravel already ships. If you are on Laravel 10+, assume the default answer is "use the framework" and justify every exception.
Debugging tactic. When a helper misbehaves and the source is opaque, isolate it in tinker with a minimal input, then read the actual function body — these are short functions and there is rarely indirection. If output depends on locale or on app()->getLocale(), confirm the app locale is set, since early-loaded helpers may capture the default rather than the request locale.
Extension points are limited by design. There is generally no driver system, no manager class, no macro registration. The only real extension points are (a) your own wrapper class, and (b) forking the handful of functions you need. Do not expect to override behaviour in place — plan for (a) from day one.
How can I help you explore Laravel packages today?