Support Laravel Package

Getting Started

Install and pin. The package is archived, so treat the version you install as a fork you now own:

composer require andrey-helldar/support

In Laravel, the service provider is auto-discovered; in standalone PHP the PSR-4 autoloader is all you need. Because upstream is frozen, commit a specific version constraint ("andrey-helldar/support": "6.17.*") and consider vendoring or forking if the helpers become load-bearing in your codebase.

Where to look first. Skip the README and read vendor/andrey-helldar/support/src/ directly — the helper classes are small and self-documenting. Identify the namespaces you'll actually use (array/string/file/JSON helpers) and confirm which are static classes versus global functions, since the two have very different ergonomics and conflict profiles.

First use case. The lowest-risk entry point is JSON and file reading — places where Laravel's own helpers are thin and where you'd otherwise write json_decode(file_get_contents(...), true) plus error handling. Replace one such block, verify behavior on a missing file and malformed JSON, and only then expand into array/string helpers.

Implementation Patterns

Use it as a thin utility layer, not a framework. The value is in eliminating three-line boilerplate blocks. Call helpers directly at the point of use for one-offs; wrap them in a small app-level Support class when the same operation appears in more than two places. That wrapper is also your escape hatch if you later drop the package.

Array access and transformation. The safe-access and transformation helpers shine in request/response shaping: normalizing nested payloads, pulling values with defaults, flattening config arrays. Pattern: validate the shape with Laravel's validator, then use the helpers purely for extraction — don't let them become your validation layer.

String formatting. Best used for presentation and identifier generation (slugs, case conversion, truncation). Keep them out of business-logic branching; if you find yourself comparing helper output to decide behavior, write the explicit comparison instead.

File and JSON utilities. Ideal for seed data, fixtures, config snapshots, and import scripts — anywhere you read structured files from disk. Pair them with Laravel's Storage facade for anything user-facing or remote-disk related; these helpers are local-filesystem oriented.

Laravel integration tip. In a Laravel app, prefer injecting/wrapping over calling static helpers inside controllers, so the helpers stay testable and swappable. In jobs and console commands, direct calls are fine — those layers are already imperative.

Standalone usage. Because the core is framework-agnostic, the same helpers work in a small CLI or a package's src/. This is genuinely useful for sharing code between a Laravel app and a companion tool, but only if you pin the version on both sides.

Gotchas and Tips

Archived means no fixes. There will be no PHP-version compatibility patches, no security updates, and no bug fixes. Audit the specific helper classes you adopt before relying on them, and re-audit on every PHP minor upgrade. If a helper becomes critical, copy the ~20 lines into your own codebase and drop the dependency.

Name collisions with Laravel. Laravel already ships Str, Arr, and a large set of global helpers. The most common failure mode is ambiguity: two Str classes, two array_get-style functions, confusing IDE resolution and autocomplete. Always import explicitly (use Helldar\Support\...\Str;) and never rely on the global namespace, especially in Blade or tinker sessions where the loaded context differs.

Global function pollution. If the package registers global functions, they load on every request regardless of use. Check the composer files autoload entry. In standalone projects, ensure the autoloader is required before any helper call, or you'll get "call to undefined function" in scripts that assume a bootstrap.

Configuration quirks. If config is publishable, publish it and commit it — an archived package's defaults will never change, but an unpublished config makes behavior invisible to reviewers. Conversely, don't publish config you don't customize; extra config files are just drift surface.

Debugging. These are pure functions over plain data, so dump()/dd() at the call site is almost always faster than stepping through. When output looks wrong, first confirm the input type — many helpers behave differently for null, empty string, and missing keys, and silent coercion is the usual culprit.

Extension points are yours, not theirs. With upstream frozen, the only safe extension mechanism is composition: your own wrapper classes that delegate to the package. That gives you a single file to patch when a helper misbehaves, and a single file to rewrite when you eventually replace the package.

Test the helpers you depend on. Write a handful of assertions around the specific helpers you use, especially around edge cases (empty arrays, non-UTF8 strings, unreadable files). This is cheap insurance against an abandoned dependency quietly changing behavior under a new PHP runtime.