Laravel Model Mapper Laravel Package

Product Decisions This Supports

Build vs. buy: still "build" — but the reason has narrowed. The 3.4.3 release weakens one of our original rejection grounds: the repository is evidently not archived and can still ship code, and Laravel 10 is now supported. That is a real, if small, correction to the record. It does not change the recommendation, because the underlying economics are unchanged — the scope is still "a collection of helper functions" that a mid-level engineer reproduces in an afternoon, and adoption still imports dependency review, security triage, and future migration work that exceeds the cost of writing the helpers ourselves.

Roadmap and dependency policy: keep screened out at the first gate. A single PR adding framework-version metadata is a maintenance signal, not an ecosystem signal. One release, no dependents, no downstream validation, and one framework version behind current (Laravel 10, not 11 or 12) does not meet the bar for a production dependency manifest. The correct roadmap line item remains a one-line ADR entry explaining the rejection, now with the added note that a 2024-era release was evaluated and still did not clear the bar.

Risk register: the metadata inconsistency is still the open item, and now more important. The package name (laravel-model-mapper) still does not match the repository URL (laravel-loop-functions), and the description ("Collection of helper functions") matches neither. The new release confirms the artifact is live on Packagist under a name that doesn't describe what it does — which makes provenance verification more urgent, not less. Any team that resolved this dependency should confirm exactly which artifact and vendor/namespace they pulled.

Use cases where it earns a narrow, non-production role: unchanged — referencing utility patterns during a spike, or mining the source for idioms when writing internal helpers. It is a reading list, not a dependency. Laravel 10 support marginally widens the prototyping window (a Laravel 10 spike will now install cleanly) but does not extend it to production.

Lifecycle decision: still no migration budget required. Adoption remains effectively zero, so there is no removal project and no user-facing change to schedule. The only update is bookkeeping: revise the ADR so it does not assert "archived," which is now factually wrong and would undermine the credibility of the rejection if challenged.

When to Consider This Package

Consider it only under a narrow and unusual combination of conditions:

• You are doing exploratory prototyping on a throwaway branch against Laravel 10 specifically, and inlining the helpers would cost more than pulling a dependency — accepting the code will not ship.
• You need a reference implementation of a specific helper pattern and want a quick, MIT-licensed example to read before writing your own.
• You are auditing an existing codebase and discover this already in composer.json; the decision there is not "adopt" but "scope the replacement." Note that the 3.4.3 release makes replacement a judgement call rather than an emergency, but the naming mismatch still argues for confirming what is actually installed.

Look elsewhere — or build in-house — in every other circumstance, specifically when any of the following is true:

• You need a currently supported Laravel version. 3.4.3 adds Laravel 10 support only. Laravel 11 and 12 remain unverified, and a single-version bump with no stated policy on cadence gives no confidence the gap will close.
• You need security patching. The repository is alive enough to merge a dependency bump, but there is still no evidence of a disclosure channel, CVE process, or maintainer commitment. One release is not a support contract.
• You need behavioural guarantees. "Collection of helper functions" remains a broad, loosely scoped surface with no published contract and no dependents to serve as a de facto compatibility check.
• Your org has a dependency policy. Active maintainer and recent release now partially pass; adoption evidence still fails outright, and release cadence is too sparse to satisfy most policies.
• The name matters. If you actually need model mapping, resolve the correct package first — the mismatch means you may not be evaluating the library you think you are.

For model mapping specifically, evaluate the established, actively maintained options in that space rather than this entry; for helpers, prefer your own app/Support namespace with tests you control.

How to Pitch It (Stakeholders)

For executives (30 seconds): We reviewed a small Laravel helper package and recommended against adoption. A new release has since shipped and corrects one of our earlier findings — the project is not abandoned — but it only adds support for Laravel 10, while the framework is already two major versions ahead. There are still no downstream users and no security or support commitments. The recommendation is unchanged: implement the handful of utilities ourselves and record the decision. Cost to act: effectively zero.

For engineering leads: Update your notes — the "archived" finding was wrong, and the package does now build against Laravel 10. That is the entire delta. It remains a low-value, high-friction dependency: no Laravel 11/12 support, no dependents for field validation, no published contract, and a scope small enough that inlining is cheaper than integration. The package-name-to-repository mismatch is unresolved and is the item I'd prioritise; if anything references this package in our tree, verify provenance before touching it. Recommended action: reject, correct the ADR wording (drop "archived," cite the version gap instead), and stand up an internal support namespace with test coverage if helpers are needed.

One-line summary: The new release proves the project is alive but not that it is supported — recommendation stands: reject, correct the ADR, and build the helpers in-house; the naming mismatch remains the only item needing active follow-up.