Laravel Model Json Laravel Package

Getting Started

This is a compatibility release, not a feature release. The entire v1.5.0 change is a Laravel version split driven by an upstream change to how Eloquent function scopes behave in Laravel 5.8. Treat the release notes as a pinning instruction first and a changelog second.

Minimal steps:

1. Determine your framework version: php artisan --version (or the laravel/framework / illuminate/support constraint in composer.json).
2. Pin accordingly — the notes are explicit and there is no "works everywhere" version:

// Laravel >= 5.8
"vendor/package": "^1.5"

// Laravel <= 5.7
"vendor/package": "~1.4.*"

3. composer update vendor/package --with-dependencies and commit the lock file.
4. Smoke-test the one thing that actually changed: any model query that goes through a package-provided local scope.

Where to look first:

• The package's own composer.json require block — confirm the illuminate/* constraint actually matches the split described in the notes. Release notes and constraints drift apart more often than you'd expect.
• The service provider (boot() / register()) to see whether scopes are registered as global scopes, macros, or plain scopeX methods on a trait. That determines your blast radius.
• vendor/vendor/package/CHANGELOG.md and the diff between the 1.4.x and 1.5.0 tags — the release notes are one line, so the source is the real changelog here.

First use case: on a Laravel 5.8 app currently on ~1.4.*, bump to ^1.5, run your scope-based queries, and confirm identical SQL output before and after (see Gotchas for the comparison technique). On a 5.7 app, do nothing — you are already correct and should stay put.

Implementation Patterns

Pin by framework version, explicitly. The single most valuable pattern with this package right now is making the version coupling visible in composer.json rather than implicit in the lock file. Avoid *, dev-master, or ranges that straddle the boundary (^1.4 alone will happily resolve to 1.5 on a 5.8 app but will also let 1.4 float on 5.7 in ways that hide the split).

Upgrade as an isolated commit. Because the change is internal to scope handling, a failed upgrade surfaces as wrong query results rather than a fatal error. Land the constraint bump alone, with a test that exercises each package scope your app depends on, so a bisect is trivial.

CI matrix on the boundary. If you support both framework lines (e.g. a package or a multi-tenant fleet), run the lowest supported (5.8.x + ^1.5) and your current LTS in parallel. Scope behaviour differences are exactly the class of bug that only appears on the older of two matrix legs.

Downstream packages: widen with care. If you publish something that depends on this package, a constraint like:

"vendor/package": "^1.4|^1.5"

is only safe if your code never inspects or re-implements the package's scope internals. If you call ->scopes() on an existing query, compose scopes, or subclass the builder the package touches, split the constraint per framework version instead — mirroring what the maintainer did.

Long-lived branches for the old line. For apps stuck on 5.7, the honest options are: stay on ~1.4.*, or upgrade Laravel first and then this package. Keep the two in one upgrade PR; upgrading the package alone on 5.7 gains you nothing.

Verify by SQL equivalence, not by green tests. Capture ->toSql() plus ->getBindings() for representative queries on both versions and diff them. Where the scopes are composed dynamically, log the query rather than asserting on a result count — a silent WHERE clause change can still return the same number of rows on a small fixture.

Gotchas and Tips

• The constraint is not advisory. ^1.5 on Laravel 5.7 will fail resolution, and ~1.4.* on 5.8 may install fine and break at runtime. Never paper over this with --ignore-platform-reqs, composer update -W, or a manual composer.json edit. If resolution fails, your framework version is the answer, not the workaround.
• "Function scope change" is the whole risk surface. Anything relying on scopeX methods — including scopes that call other scopes, use $this inside the scope body, or return something other than the builder — is where regressions will land. Grep your codebase for scope[A-Z] and for calls to the package's documented scope names, and test each one individually.
• Global scopes are a separate mechanism. If the package registers global scopes, they are unaffected by the local-scope change but are affected by withoutGlobalScopes(). Verify that any withoutGlobalScope(...) calls still name the right class after the upgrade.
• Chaining and precedence. Composed scopes ($query->foo()->bar()) are order-sensitive. Confirm the emitted SQL retains the same clause ordering post-upgrade; a reordered where can change results on soft-delete, tenant, or status filters even though the intent was identical.
• Debugging toolkit. ->toSql(), ->getBindings(), DB::listen(), and ->dumpRawSql() (if available in your framework line) are the fastest way to spot a scope behaving differently. Prefer these over dd() on the builder.
• Extension points over forks. If a scope misbehaves in a way you can't wait on, override it in your model or register a local macro rather than vendoring the package. A fork pins you to a version that will diverge from upstream's framework matrix.
• 1.4.x is now maintenance-only. Expect no backports to the ≤5.7 line beyond critical fixes. Plan the Laravel upgrade rather than assuming the old branch stays healthy.
• Treat 1.5.0 as low-risk but unverified. One line of release notes and no API additions suggests an internal-only change, but that also means there is nothing to read about what changed. Run the smoke test; don't infer safety from the absence of features.
• Watch for a 1.5.1. Compatibility-only releases with terse notes frequently get a follow-up patch once the first wave of 5.8 users hits the edge cases. Subscribe to releases before rolling this out beyond one app.