Laravel Model Mapper Laravel Package

Getting Started

Verify what you're actually installing first. The package name (michael-rubel/laravel-model-mapper) and the repository URL (michael-rubel/laravel-loop-functions) disagree, and the description ("Collection of helper functions") matches neither a model mapper nor a documented loop API. Before writing a single line of application code, run:

composer require michael-rubel/laravel-loop-functions:3.4.3
composer show michael-rubel/laravel-loop-functions

Then open vendor/michael-rubel/laravel-loop-functions/ and read three things:

1. composer.json — the autoload.files entry tells you exactly which files are eagerly loaded on every request, and the require block tells you the maximum Laravel/PHP version it was tested against. Release 3.4.3 explicitly advertises Laravel 10 support, so ^10.0 should resolve cleanly; Laravel 11/12 remains unverified.
2. src/ — global helper packages are usually a handful of 10–30 line function files. Read all of them; that's your entire API surface and it takes five minutes.
3. README.md — for a package with 17 stars and 0 dependents, the README is the only documentation you will ever get.

There is nothing to publish and typically no service provider to register beyond what composer.json declares — helper-function packages rely on Laravel's package auto-discovery plus Composer's files autoloading. If a config file exists, publish it with php artisan vendor:publish --tag=<package>-config and commit it, because the upstream default will never change again.

First use case: identify one place in your codebase where you have a foreach that exists purely to build an array, count iterations, or repeat an operation N times — a seeder, a report generator, a batch job. Replace it with the package helper, run the existing test suite, and confirm behaviour is byte-identical. That single swap tells you whether the helper's semantics (return type, key preservation, early-exit behaviour, handling of empty input) match your expectations. Do not roll it out across the codebase until you've done this once.

Set expectations up front. 17 stars, 0 dependents, and only one merged PR (#5, the Laravel 10 bump) visible in recent history. 3.4.3 is a compatibility patch, not a revival: no Laravel 11/12 work, no security patches, and no evidence of active bug triage. Treat it as a vendored snippet library, not an infrastructure dependency.

Implementation Patterns

Wrap the helpers behind your own facade or class. This is the single most valuable pattern for a dormant micro-package. Instead of calling the global functions directly from 40 call sites, create one thin class:

namespace App\Support;

final class Loops
{
    public static function times(int $count, callable $callback): array
    {
        return loop_times($count, $callback); // whatever the real name is
    }
}

Now upgrading, replacing, or inlining the package is a one-file change instead of a grep-and-replace across the app. It also gives you a place to add the declare(strict_types=1) and return types the original functions likely lack.

Use them at the edges, not in the domain. Helper functions that build arrays or repeat callbacks are convenient in seeders, factories, console commands, report builders, and test data setup. They are a poor fit inside domain services where an explicit foreach communicates intent better and where you want to avoid a global-function dependency in code that outlives the package.

Pair with Collection rather than replacing it. If the helpers return plain arrays, chain them into collect() for the rest of the pipeline:

$rows = collect(loop_helper($source))
    ->filter(fn ($row) => $row['active'])
    ->chunk(500)
    ->each(fn ($chunk) => $this->upsert($chunk->all()));

This keeps the package's footprint to the one thing it does well and lets Laravel's own, maintained, well-documented API handle everything else.

Isolate it in tests. For any behaviour you depend on, write a characterization test against the package function, not just against your calling code:

it('returns an empty array for a zero count', function () {
    expect(loop_helper(0, fn () => null))->toBe([]);
});

When (not if) you eventually swap the package out, these tests are your specification for the replacement.

Plan the exit from day one. Because the functions are tiny, the realistic migration is a one-off: copy src/*.php into app/Support/helpers.php, add it to your own composer.json autoload.files, composer dump-autoload, delete the dependency. Budget an hour for this and do it the first time the package blocks a framework upgrade — don't wait for it to become an emergency.

Gotchas and Tips

Global function collisions are the number one risk. Packages that register autoload.files pollute the global namespace for the whole process. If two packages define loop() (or whatever the names are), Composer's file ordering decides which one wins and you get a fatal Cannot redeclare error or, worse, silently different behaviour. Before adopting, grep your vendor/ for the function names:

grep -rn "function loop_helper" vendor/ --include=*.php

Then wrap the include in a guard in your own code and consider forking the functions into your app namespace (App\Support\loop_helper) to make collisions impossible.

The package name/repo mismatch is a real trap. michael-rubel/laravel-model-mapper and michael-rubel/laravel-loop-functions are different packages with different purposes. If you require one and read the docs for the other, you will write code against an API that doesn't exist. Confirm the installed name appears in composer.json before you trust any README snippet — including the ones in this package's own repo, which may be a copy-paste from a sibling package.

Static analysis will not see the functions. PHPStan, Psalm, and PhpStorm's indexer don't resolve functions loaded via autoload.files unless they're in the analysed path set or you provide stubs. Practical fixes: add vendor/michael-rubel/*/src to your PHPStan scanFiles, or write a small _ide_helper.php stub file with the signatures (generated from the actual source, so they stay correct). Without this, every call site shows as an undefined function and your CI baseline breaks.

Composer's file autoload is cached aggressively. After install, upgrade, or any composer.json edit, run composer dump-autoload. A stale vendor/composer/autoload_files.php is the usual cause of "the function works in tinker but not in the HTTP request." This bites especially hard when moving from 3.4.2 → 3.4.3, because the only change in the release is package metadata; the function bodies are unchanged, so any behavioural difference you observe after the bump is your environment, not the code.

Check the empty-input and edge semantics deliberately. These helpers were written quickly and never hardened. Test: zero count, negative count, null, associative arrays, callbacks that return void, and callbacks that throw. Also check whether keys are preserved or re-indexed — this silently breaks array_combine and array_map callers downstream. The 3.4.3 changelog contains no behavioural fixes, so every semantic quirk you find in 3.4.2 is still present here.

Pin the version exactly and mirror the source. Use an exact constraint ("michael-rubel/laravel-loop-functions": "3.4.3", no caret) so a fresh composer install on a new machine can't drift — especially important because a caret would let a future patch release in with no review, and the project has no recent track record of releasing. Then create a private fork or a README note in your repo pointing at the exact commit you depend on, because the upstream URL can disappear and take your build with it.

The framework ceiling is the real blocker. 3.4.3 lands on Laravel 10 and stops there; it predates Laravel 11 and the PHP 8.3+ deprecation cycle. If your composer.json requires laravel/framework: ^11.0, composer require will fail on constraints — and if you force it with --ignore-platform-reqs, you own whatever breaks. The correct response at that point is the vendoring migration described above, not a constraint override.

Treat the release as a compatibility signal, not a maintenance signal. PR #5 ("Laravel 10 support 🏷") is the only activity shown in the changelog between 3.4.2 and 3.4.3 — there are no feature additions, no bug fixes, and no documentation updates. Do not read a green composer require on Laravel 10 as evidence that the package is actively maintained; the maintainer merged a label/metadata change and stopped. With 0 dependents and 17 stars, any bug you file is effectively a bug you fix. If you find one, patch it locally and keep the diff in a patches/ directory with cweagans/composer-patches, or just fork — both are cheaper than waiting on a maintainer who has moved on.