Composite Primary Keys Laravel Package

Getting Started

What this release tells you: v1.12.1 is a compatibility patch — the package now declares support for Laravel/Lumen 7. Nothing about features, fixes, or API changes. The "fingers crossed" note is the important signal: the maintainer shipped it quickly, so treat 7.x support as claimed rather than verified until you've exercised it yourself.

Minimum steps to evaluate:

1. Confirm the actual constraint change before assuming anything:

   composer show vendor/package --all | head -20
   git diff v1.12.0..v1.12.1 -- composer.json
   

   Look for illuminate/support: ^7.0 (or ^6.0|^7.0 if 6.x is still supported). This single line determines whether you can install it at all.
2. Install into a throwaway Laravel 7 app first — not your production-adjacent project:

   composer require vendor/package:1.12.1
   php artisan vendor:publish --provider="Vendor\Package\ServiceProvider"
   

3. Exercise the package's single most important code path by hand. Read its README for a one-liner and run it in php artisan tinker. If that works, run its own test suite if it ships one, and your app's suite afterwards.
4. Only then loosen your composer.json constraint and roll it into a real branch.

Lumen is a different path. There is no auto-discovery and no vendor:publish workflow. You'll register the provider manually in bootstrap/app.php, and if the package ships a config file you must both copy it into your project and call $app->configure('package-name') — Lumen does not load package configs implicitly. If the package uses facades, you also need $app->withFacades() enabled.

First use case: a greenfield Laravel 7 service or a small non-critical feature, where a package regression costs you an afternoon rather than an incident. Don't make v1.12.1 your introduction to this package on a legacy 6.x app you're mid-upgrade on.

Where to look first: the diff for v1.12.1 (it should be tiny — a constraint bump, maybe a CI matrix entry), then the package's CI config to see whether Laravel 7 is actually in the test matrix or merely in composer.json. The gap between those two is exactly where "fingers crossed" lives.

Implementation Patterns

Wrap it before you depend on it. Even for a stable package, put a thin adapter between your application code and the package's API:

// app/Services/YourDomain/ThingGateway.php
interface ThingGateway { public function doThing(array $payload): Result; }

class PackageThingGateway implements ThingGateway { /* delegates to vendor package */ }

Bound in a service provider. This costs ten minutes and means a broken v1.12.2 costs you a one-line swap instead of a refactor. It matters most precisely when a maintainer ships compat patches with visible uncertainty.

Pin during evaluation, loosen after. Require 1.12.1 exactly while you're validating. Once it survives a week in staging, move to ^1.12 so you pick up patch fixes — but understand what you've accepted: if the constraint is ^7.0 on the framework side, future Laravel 7 patches come along for free, which is usually what you want and occasionally isn't.

Add a smoke test to your suite. The package's own tests prove the package works in isolation. Yours prove it works with your container bindings, your config overrides, and your event listeners:

public function test_package_core_path_still_works(): void
{
    $result = app(ThingGateway::class)->doThing(['example' => 'payload']);
    $this->assertSame(Result::OK, $result->status);
}

This is the test that catches the next compat bump without you reading release notes.

Dual-version support. If you maintain code that must run on both Laravel 6 and 7, get the package into a CI matrix that actually boots both. Laravel 7 moved to Symfony 5 components and made smaller behavioural changes (TestResponse, HTTP client, date serialization) that a constraint bump alone doesn't cover. Run your own suite against both laravel/framework:^6.0 and ^7.0 in CI before trusting the claim.

Lumen integration checklist:

// bootstrap/app.php
$app->withFacades();          // only if the package uses facades
$app->configure('package-name');
$app->register(Vendor\Package\ServiceProvider::class);

Then verify the config file you copied hasn't drifted from the package's current default — Lumen users are the ones most likely to be running stale published config after an upgrade.

Use Composer's patch escape hatch. If v1.12.1 is almost right, don't fork the package. Use cweagans/composer-patches with a local diff, or a VCS branch alias (dev-fix/laravel7 as 1.12.1). Keeps you off a private fork you'll forget to maintain.

Gotchas and Tips

• "Fingers crossed" is the release note. Read it literally: the maintainer tested enough to merge, not enough to guarantee. Do not bump this on a Friday onto a path that touches money, auth, or migrations without a manual pass.
• Laravel 7 is the ceiling here. Nothing in the note claims 8.x. If your roadmap includes upgrading the framework again, this package is now a known dependency to check — note it, and re-evaluate at that point rather than assuming forward compatibility.
• The constraint may be narrower than you think. ^7.0 and 7.* behave identically today but signal different maintainer intent. Also check whether 6.x support was dropped in this release — a package that switched from ^5.8|^6.0 to ^7.0 will silently break any sibling service still on 6.
• Dependency conflicts surface as install failures, not runtime errors. If composer require won't resolve, diagnose with:

  composer why-not vendor/package 1.12.1
  composer show -t | grep -i illuminate
  

  Usually a transitive package still pinning illuminate/*:^6.0.
• Package discovery is cached. After bumping, run php artisan package:discover (or composer dump-autoload) before concluding the provider isn't registering. In Lumen this is moot — it's manual, and forgetting the registration is the #1 "the package does nothing" cause.
• Lumen config is the second-most-common failure. Published config + configure() call, both required. Symptom: package falls back to hardcoded defaults and behaves subtly differently than in your Laravel app.
• Check what it does at boot. Time the provider's register()/boot() if the package does anything dynamic — a package that suddenly queries the DB or hits the network on every request after a version bump is worth catching in staging.
• Extension points to prefer over patching: container bindings for its interfaces, published config for behaviour toggles, and its events/listeners for hooks. Reaching for a fork means you've given up on upstream — do that only when the maintainer is unresponsive, which one quick patch release doesn't establish.
• Watch the next release. If v1.12.2 arrives within days with a fixed bug, that confirms the "fingers crossed" read. Let two or three patch releases land before you consider this version boring.