Laracrate Laravel Package

Product Decisions This Supports

• Build vs. buy for Laravel-side plumbing. Unchanged in principle: this is generic framework glue, so the question remains whether 2–5 engineer-days of reimplementation beats taking a dependency. What has changed is the price of the dependency — see the version-churn point below.
• Dependency adoption and upgrade gates — now validated, not hypothetical. Our previous assessment proposed a policy tier for minor bumps. The 1.3.0 → 2.1.0 jump answers whether that policy matters: the package crossed at least one major version boundary (2.0.0 exists; we are now on 2.1.0) in the interval since we last looked. Had we adopted 1.3.0, we would be mid-migration today on code we had not yet finished evaluating. That is the concrete cost of a "just take the dependency" decision, and it should be cited in the next build-vs-buy conversation.
• Roadmap timing and risk buffer — upgrade line item is now real, not notional. Previously we named the Laravel-upgrade tax as a small recurring line item. A major-version break inside one review cycle means the tax is front-loaded: the package's own API surface moves, not just its Laravel compatibility. Budget for it explicitly if anyone proposes adoption.
• Vendor/SPOF risk register. Unchanged and still a single-maintainer continuity dependency. The rapid major-version cadence is a second-order signal here: active maintenance is good, but major-version churn on a utility package without a written migration guide is maintenance activity rather than maintenance stability — those are different risk profiles.
• Release-notes quality as a procurement gate. Our prior assessment listed "release notes are routinely non-descriptive" as a walk-away condition. That condition has now fired twice consecutively (1.3.0 and 2.1.0, both bare compare/... diff links). It is no longer an anomaly to be excused by one lazy release; it is the maintainer's documented practice. That converts a provisional caveat into a standing finding.
• Use cases it plausibly serves: unchanged — internal admin/tooling scaffolding, prototypes and spikes, non-customer-facing utilities. Nothing in the new release broadens this to customer-facing surface, and we have no evidence to suggest it should.

Evidence status (updated): The prior assessment held adoption on the grounds that 1.3.0's notes were a bare diff link and nothing confirmed the release was non-breaking. Two data points later, the picture is clearer in both directions. Against: the project has moved through a full major version (2.0.x) with no published changelog, so we cannot say what broke or why, and 2.1.0's notes are again only a diff link. For: 2.1.0 relative to 2.0.1 is a minor bump, and the project is demonstrably still being released rather than abandoned. This assessment remains provisional and is now more conservative, not less. Adoption requires reconstructing the 1.3.0 → 2.1.0 changelog by reading commits and tags — that is the entry fee, and it is higher than it was last review.

When to Consider This Package

Consider it only when all of the following hold:

• The functionality is off the critical path — internal tooling, dev ergonomics, or a feature removable in a sprint without customer impact. Non-negotiable given the churn above.
• It constrains its supported Laravel and PHP versions in composer.json and those match our current and next-planned framework version. Re-verify against 2.x specifically; 1.x-era constraint checks are stale and should not be carried forward.
• A readable CHANGELOG or tagged release history exists with more substance than a diff link. On current evidence this package does not meet this criterion — treat it as an unmet gate requiring a documented exception, not a box to tick optimistically.
• License is compatible with our distribution model (MIT-style fine; copyleft or commercial terms need legal sign-off).
• Test coverage and CI are visible and passing on the 2.1.0 tag specifically, not on main or on the last version anyone happened to look at.
• We have a named owner internally — one engineer to patch, fork, or replace it — and that person has actually read the 1.3.0 → 2.1.0 delta.
• New: there is a written migration note or upgrade guide for the 2.x line, or the owner has reconstructed one. Major-version jumps without migration documentation mean every future upgrade is a re-evaluation, which defeats the point of buying the dependency.

Look elsewhere, or vendor a copy, when:

• The package would sit on a payment, auth, PII, or data-integrity path. Unchanged, and the intervening major release only strengthens this.
• Release notes are routinely non-descriptive — this condition is now met. Both recent releases are bare diff links. Unless a maintainer-published changelog appears, plan to read every diff by hand or do not adopt.
• The last release is more than ~12 months old with unanswered issues or PRs. Not currently the case; the project is active.
• The same capability exists in Laravel first-party or a package we already depend on. Every dependency is a permanent tax on every framework upgrade — and, as of this release, on every package upgrade too.
• It is used in a multi-tenant or security-sensitive surface and the security disclosure process is undocumented.
• New: we would be adopting mid-major-line with an unreviewed breaking change behind us. Prefer to wait for a settled 2.x with at least one maintenance release after the next major, or vendor the code and pin it ourselves.

How to Pitch It (Stakeholders)

For executives (30 seconds): The Laravel utility package we flagged last cycle (edulazaro/laracrate) has published a new version, 2.1.0. Two things have changed since we last looked, and they point in opposite directions. The project is clearly alive — it has shipped through a full major version since our review, which means it is not abandoned, and that was our biggest single worry. But it also means the package has had at least one breaking release in the time we have been evaluating it, and, as before, the release notes are nothing but a link to the code diff. If we had adopted the version we reviewed last cycle, we would be doing a migration right now on something we had not finished vetting. My recommendation is therefore unchanged but firmer: no adoption on anything customer-facing, and if a team wants it internally, a time-boxed trial behind an adapter with a written exit plan — but only after an engineer reconstructs what actually changed between the version we reviewed and this one. The realistic risk was never that the package is bad today; it is that it moves under us without documentation, and that risk is now demonstrated rather than predicted.

For engineering (the ask): Four things, and the first one is bigger than last time. (1) Reconstruct the 1.3.0 → 2.1.0 changelog from the commit history and tags, and tell me what broke in 2.0.0 and whether any of it affects the use case we care about — the published notes will not tell us. (2) Re-check composer.json constraints against 2.1.0 for our current and next Laravel version; do not reuse the 1.x answer. (3) Confirm the license and that CI actually runs green on the 2.1.0 tag, and check whether the 2.x line pulled in new transitive dependencies. (4) Name an owner. If all four come back clean, the trial still goes behind a single adapter/interface in an internal tool, so replacement is a one-file change — that containment is the entire point, and this release is the argument for it: a major version landed and it cost us nothing only because we had not committed. Default to "no" for anything customer-facing, and note that the "empty changelog" condition in our adoption checklist is now formally triggered — a team that wants to proceed needs a written exception, not a verbal one.