Getting Started

Install it as a plain Composer dependency:

composer require zicht/util

There is no Laravel service provider, facade, config file, or migration step to publish. It is a low-level PHP utility library, so you use its classes directly via their namespaces.

Start by reading the source for the workhorse classes, typically:

src/Str.php — string casing, slugging, truncation, comparison helpers
src/Arr.php — array access/manipulation helpers
src/Debug.php — dump/backtrace/timer-style debugging helpers
src/Shell.php — shell command helpers, if present in your version
tests/ — the fastest way to confirm exact behavior for edge cases

A good first use case is input normalization in a Laravel FormRequest or model mutator:

use Zicht\Util\Str;

$data['slug'] = Str::slugify($request->input('title'));
$data['name'] = Str::camelize(trim($request->input('name')));

Use it where you would otherwise write tiny private helper methods for string/array plumbing. Do not treat it as a Laravel replacement for Illuminate\Support\Str or Illuminate\Support\Arr; treat it as a small toolbox for gaps those helpers do not cover.

Implementation Patterns

Normalize request input before validation or persistence

Use Zicht\Util\Str in FormRequests, controllers, or action classes to make incoming data consistent before it reaches your domain layer.

use Zicht\Util\Str;

protected function prepareForValidation(): void
{
    $this->merge([
        'slug' => Str::slugify($this->input('title')),
        'name' => Str::camelize(trim($this->input('name'))),
    ]);
}

This keeps casing/slug rules in one place instead of scattering str_replace, preg_replace, and trim calls across controllers.

Use in Eloquent accessors and mutators

For model-level formatting, call the utility from a mutator or accessor:

use Zicht\Util\Str;

public function setSlugAttribute($value): void
{
    $this->attributes['slug'] = Str::slugify($value ?: $this->title);
}

Keep the utility call thin. If the rule is business-specific, put the rule in a dedicated method or service and let zicht/util handle only the low-level string operation.

Wrap vendor static calls in app-level helpers

Because most usage is static, direct calls create vendor coupling. A small app helper improves testability and makes replacement easier:

namespace App\Support;

use Zicht\Util\Str;

final class Text
{
    public static function slug(string $value): string
    {
        return Str::slugify($value);
    }
}

Then use App\Support\Text::slug() throughout the application. This also protects you from method-name changes or package abandonment.

Use in console commands and operational scripts

zicht/util can be useful in Artisan commands, jobs, and deployment scripts for small string/array/debug tasks. For example, use its debug helpers during local troubleshooting, but keep them out of production paths.

use Zicht\Util\Debug;

Debug::dump($payload); // confirm behavior in the package version you install

For shell-related helpers, treat them as operational utilities: escape arguments, avoid user-controlled command fragments, and prefer Laravel’s Process component when you need robust process handling.

Blade and view usage

Static calls work in Blade, but avoid making templates depend heavily on vendor utilities:

{{ \Zicht\Util\Str::slugify($post->title) }}

If you use it frequently in views, register a Blade directive or expose a view helper in App\Support instead.

Gotchas and Tips

No Laravel integration is provided. There is no service provider, facade, config, or auto-discovery. Import classes explicitly and run composer dump-autoload if a class is not found.
Watch namespace collisions. Zicht\Util\Str and Zicht\Util\Arr can collide mentally with Illuminate\Support\Str and Illuminate\Support\Arr. Use aliases when both are imported:
```
use Zicht\Util\Str as ZStr;
use Illuminate\Support\Str;
```
Do not assume Laravel semantics. A Zicht\Util\Arr::get() may not support dot notation the way data_get() does, and string helpers may not be multibyte-safe. Check the package tests or write a one-line test before relying on edge-case behavior.
Static methods are hard to mock. Wrap them behind app-level helpers if the behavior matters in unit tests or may need to be swapped later.
Be careful with debug helpers. Methods that dump, print, or halt execution should never be left in request paths. Use them locally and remove or guard them before deployment.
Treat shell helpers as security-sensitive. Escape arguments and never interpolate unsanitized request data into commands. If the package’s shell helper is too thin for your needs, use Symfony Process or Laravel’s process APIs instead.
Validate XML behavior before using it on untrusted input. If the package includes XML conversion helpers, confirm whether external entities are disabled and whether the output shape matches your expectations.
Pin the version. Since this is a small, low-level utility package, pin a known-good version in composer.json and cover the specific helpers you depend on with tests.
Prefer Laravel helpers first. Use Illuminate\Support\Str, Arr, data_get(), and Process when they already solve the problem. Reach for zicht/util only when it gives you a concrete, tested shortcut.
Extension point is composition, not configuration. There is unlikely to be a config file or macro system. Extend by wrapping the utility in your own helper/service, or fork the package if you need to change behavior.

Util Laravel Package