Functions Laravel Package

Getting Started

itul/functions is a Composer package that ships global PHP functions — the kind you typically end up writing into app/helpers.php. There is no service provider, no config file, and no facade. Installation is the whole onboarding.

composer require itul/functions

Where to look first:

1. vendor/itul/functions/composer.json — confirm it uses "autoload": { "files": [...] }. That is the only mechanism a function package can use, and it tells you the files get loaded on every request.
2. vendor/itul/functions/src/ — run grep -rn "function " vendor/itul/functions/src to get the actual inventory. Do this before writing code against it; the package metadata gives you no API surface.
3. vendor/itul/functions/README.md — if present, scan for examples and any documented PHP version floor.

If composer require succeeds but functions are "not found", run composer dump-autoload — Composer's files autoload is only registered at dump time, and a stale vendor/composer/autoload_files.php is the usual culprit.

First use case: pick one genuinely repetitive transformation in your codebase (array reshaping, string normalization, safe casting) and replace three or four inline copies of it. Verify the function exists in the vendor source first, then call it from php artisan tinker:

>>> function_exists('the_function_name')
=> true

Only then refactor call sites. Because these are global functions, there's no import, no use statement, and nothing to mock — which is precisely why you validate before adopting.

Implementation Patterns

Treat it as a polyfill layer, not a dependency. Global function packages are effectively appended to the PHP language at runtime. Use them the way you'd use str_contains() — casually, in leaf code, never as an architectural boundary.

Establish a naming audit before adoption. Laravel already ships an enormous helper surface through Illuminate\Support (Str, Arr, head, last, blank, filled, data_get, transform). Before using an itul/functions helper, check function_exists() inside a bootstrapped app — Laravel defines many global helpers and Symfony polyfills define others. Anything already present is dead weight and a future collision.

Prefer call sites that are cheap to reverse. Instead of sprinkling calls across fifty files, keep a thin app-owned wrapper for the handful you actually use:

// app/Support/Helpers.php
if (! function_exists('slugify_title')) {
    function slugify_title(string $value): string
    {
        return the_itul_function($value); // single call site to swap out
    }
}

This costs almost nothing and gives you a one-file migration path if the package goes stale. It also gives PHPStan a typed signature, which the vendor source may not provide.

Use it in the places where helpers shine: Blade directives and view data preparation, FormRequest::prepareForValidation(), seeders and factories that massage fixture data, and Artisan commands doing one-off data cleanup. Avoid it in domain services, value objects, or anything you'd want to unit test with doubles — you cannot mock a global function without namespace trickery.

Version-lock hard. This package has no stars, no dependents, and lives on Bitbucket. Pin an exact version in composer.json ("itul/functions": "1.2.3" rather than ^1.0) and commit composer.lock. A silently-published patch that renames or removes a function is a fatal error across your entire app, at autoload time, before any of your code runs.

Test the helpers you depend on. Because the package ships no test signal you can inspect, write a small characterization test suite of your own:

it('exposes the itul helpers we rely on', function () {
    expect(function_exists('the_itul_function'))->toBeTrue();
});

This turns a silent breakage (function removed) into a red test in CI rather than a white screen in production.

Gotchas and Tips

Autoload order is not yours to control. Composer loads files autoloads in dependency-resolution order. If another package or a Laravel polyfill defines the same function name, whichever loads second triggers a Cannot redeclare fatal. This is the single most likely failure mode for this class of package. Debug with:

php -r "require 'vendor/autoload.php'; var_dump(function_exists('suspect_name'));"

and inspect vendor/composer/autoload_files.php to see ordering.

Opcache and preloading. Functions live in a file that's loaded on every request. On PHP-FPM with opcache.preload, preloading a file full of global functions is fine, but opcache.validate_timestamps=0 in production means a composer update requires an FPM reload — the new function set will not appear until workers recycle. Same applies to long-running workers (Octane, Horizon, queue daemons): restart them after any Composer change.

Static analysis will not see these. PHPStan and Psalm cannot infer signatures from global functions without a stub file. You'll either get "function not found" errors or, worse, silently untyped mixed returns that flow into typed properties. Mitigations:

• Add vendor/itul/functions/src to PHPStan's scanFiles, or
• Write a small .stub file declaring the functions you use, or
• Route everything through your own wrapper (see above) with real type hints.

IDE autocomplete requires a dump. After install, run composer dump-autoload and let the IDE index vendor/. barryvdh/laravel-ide-helper does not help here — it generates model and facade stubs, not arbitrary function stubs. If completion still fails, check the package isn't excluded by your IDE's vendor indexing rules (PhpStorm indexes vendor only if it's marked as a library source).

No extension points. There is no config, no container binding, no macro system. If you need variant behavior, wrap the call — do not fork the package into app/ unless you're prepared to own it, and if you do fork, drop the Composer dependency entirely so the functions aren't loaded twice.

Debugging "function not found" in production but works locally almost always means: (a) production deployed without composer install --no-dev running after the composer.json change, (b) the package was dropped as a transitive dev dependency, or (c) OPcache is serving a stale function table. Check vendor/itul/functions exists on the server first, then restart workers.

Avoid it for anything security-relevant. No stars, no dependents, no visible CI — you have no evidence these helpers are fuzz-tested. Never use them for hashing, signature comparison, random token generation, or escaping. Use hash_equals, random_bytes, e(), and framework primitives instead.

Long-term risk assessment. Score 0, no stars, single Bitbucket host. Budget for the possibility that the repo disappears or stops receiving PHP-version compatibility updates. The wrapper pattern above is the cheap insurance: when adoption spreads, you can inline the five functions you actually use into app/Support/helpers.php, delete the dependency, and never notice.