Laravel Pastable Model Laravel Package

Product Decisions This Supports

• Platform upgrade gating. v0.2.0 jumps to PHP 8.2+/Laravel 11 only. This release is effectively a compatibility signal, not a feature release: if our product still ships on Laravel 9 or 10, this package is now unusable and we should either stay pinned to v0.1.0 or exclude it from the roadmap. Conversely, if we are already on Laravel 11, this is the first version we can safely install.
• Build vs. buy on a small surface area. This is a thin convenience layer on top of Eloquent — the kind of behavior an engineer could reimplement as an in-house trait in a day or two. The decision is not "can we build it" (we can) but "is a 0.x third-party dependency cheaper than owning ~100 lines of code."
• Dependency-floor hygiene. The release also bumps CI/tooling actions only (checkout, Pint, composer-install, auto-commit, fetch-metadata). There are no new features, no deprecations, and no API changes. That means the upgrade carries near-zero functional risk and near-zero functional upside — it is a maintenance move, not a capability unlock.
• Feature/use-case fit. Adopt only where we actually have a repeating "recreate/paste this model" workflow in the product (templates, duplication, seed-style demos). If no such use case is on the roadmap, this package adds a dependency we will never exercise.

When to Consider This Package

Adopt when all of the following hold:

• We are on Laravel 11 with PHP 8.2+ (mandatory as of v0.2.0).
• We have a concrete, near-term use case for duplicating/pasting model state, not a speculative one.
• We are comfortable pinning to an exact 0.x version ("^0.2.0" with a lockfile) and treating the API as unstable — pre-1.0 semver means a future minor release can break us.
• The package is small enough to vendor or fork if the maintainer goes quiet; we accept single-maintainer, community-scale support with no SLA.

Look elsewhere (or build in-house) when:

• We are on Laravel 9/10 or PHP < 8.2 — v0.2.0 will not install, and staying on 0.1.0 means running an abandoned branch.
• We need stable public APIs, long-term support guarantees, or a security response commitment.
• The behavior touches core data-integrity paths (mass duplication, cloning with relations) where we want first-party test coverage we control.
• The cost of an in-house trait is lower than the cost of tracking upstream 0.x churn — which, for a package this size, is a realistic outcome.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk convenience library for Laravel, not infrastructure. The new release (v0.2.0) adds no features — it simply raises the requirement to Laravel 11 / PHP 8.2 and refreshes CI tooling. The decision it forces is really a platform decision: we can only use it if we are already on Laravel 11. Recommendation: no spend, no commitment; evaluate only alongside a concrete duplication/paste use case and pin the version.

To engineering: v0.2.0 is a Laravel 11 / PHP 8.2 floor bump plus Dependabot action updates — no API changes, no deprecations. It is pre-1.0, single-maintainer, and thin enough to replace with an in-house trait. If we adopt, pin it, wrap it behind our own interface so the dependency is swappable, and do not let it sit on a critical write path without our own tests.