Admin Ui Laravel Package

Getting Started

The headline signal in v7.0.0 is not a feature — it is the versioning contract. The package now tracks Laravel's major release numbers, so package ^7.0 means "built for Laravel 7." Treat the major number as a compatibility key, not a semver-ish quality signal.

Minimal path to first use:

1. Match majors first, then resolve. Your composer.json constraint should mirror your framework constraint:

   "require": {
       "laravel/framework": "^7.0",
       "vendor/package": "^7.0"
   }
   

   If your app is still on Laravel 6, this release will not resolve — there is no cross-major compatibility implied by the notes. Expect to either stay on the package's v6 line or upgrade the framework first.

2. Confirm the Laravel 7 baseline. Laravel 7 ships Symfony 5, symfony/console and symfony/http-foundation bumps, and a PHP floor of 7.2.5. Check composer show vendor/package after install and verify the require block's PHP and illuminate/* constraints line up with what you actually run. This is the single fastest way to catch a broken constraint before it bites in staging.

3. Let auto-discovery do its job, then verify. Laravel 7 still supports package auto-discovery; if the service provider does not appear in php artisan about / bootstrap/cache/packages.php, the provider is either not registered in the package's composer.json extra.laravel block or you have a stale package manifest — php artisan package:discover refreshes it.

4. Publish and diff. Before using the package, run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and commit the published config before touching it. That baseline diff is what makes future major upgrades readable.

First use case to reach for: the read/query path rather than the write path. Get a single happy-path call working end to end in a feature test, confirm the config is being read from the published file (not the package default), and only then wire it into queued jobs or scheduled commands. Most package breakages on a major bump surface in resolution and container binding, not in business logic — so prove the wiring first.

Implementation Patterns

Version pinning as a first-class concern. Because the package major now equals the Laravel major, your upgrade runbook should be a single paired event: Laravel 7 → 8 and package 7 → 8 happen in the same branch, the same PR, ideally the same commit. Splitting them creates a window where no valid constraint exists for either.

Keep the lockfile authoritative. For application code, commit composer.lock and use composer install everywhere including CI and Docker builds. composer update should be a deliberate, reviewed action — especially after a major-tracking version scheme lands, because every framework minor bump will pull a package minor bump with it.

Environment-specific config, not env-specific code. Bind the package's config through config/package.php with env() calls living only inside that file. Laravel 7 broke the habit of env() working reliably outside config files once config caching is on — after php artisan config:cache, any env() call in application code returns null. Guard against this by running at least one staging deploy with cached config.

Wrap the package behind a thin abstraction. A one-class-or-one-interface seam around the package's public API costs an hour and pays for itself at the next major. When v8 lands, you change the implementation of the seam rather than grepping for call sites. This matters more than usual here: the release notes make no promise of API stability across majors, only version-number alignment.

Feature-test the integration, not just the package. Package majors frequently change the container binding shape (constructor signature, optional dependency injection, changed return types). Write one test per call site that asserts your expectations of the response, not the package's. Those tests are your upgrade safety net, and they are cheap.

CI matrix discipline. If you maintain a package or internal library depending on this one, run a matrix that pairs Laravel 7 with the lowest and highest supported PHP 7.x. Laravel 7's Symfony 5 dependency is stricter about return types and deprecations than 6's Symfony 4, and those failures show up at the framework's edges.

Upgrade choreography for an existing app. Sequence it as: (a) composer require --dry-run to see the resolution, (b) bump the constraint and run composer update vendor/package --with-dependencies, (c) php artisan config:clear && php artisan cache:clear, (d) re-publish config with --force into a scratch copy and diff against the committed baseline, (e) run the integration tests from the seam. Steps (c) and (d) catch the majority of "it silently does nothing" reports.

Gotchas and Tips

The version scheme is a trap for wildcard users. Anyone with "vendor/package": "^6.0" and a wildcard on the framework will find v7.0.0 simply never installs, with a resolution error that mentions the framework and not the package. Read composer's conflict output bottom-up — the constraint that failed is usually the last line, not the first.

Do not read the major number as "breaking for me." A v7.0.0 that exists primarily to align with Laravel 7 may have fewer breaking changes than a typical major — or the framework bump itself may be the breaking part (Symfony 5, container changes, string/date behaviour). Do not assume a migration guide exists; the release note here contains none, which is itself information worth noting in your upgrade ticket.

Config cache is the most common post-upgrade footgun. After upgrading, always php artisan config:clear. Laravel 7's config caching is aggressive; a cached config from the old package version will mask new keys entirely, and the failure mode is "my new option is ignored" with no error.

vendor:publish --force will destroy local customisation. Publish to a scratch directory, diff, then merge manually. Adopt this as policy from the first install, not from the first incident.

Watch for the service provider registration shape changing. If the package switched to deferred providers, $app->register() order stops mattering but resolve order does — a deferred binding will not appear during php artisan config:cache warm-up. If a package command mysteriously disappears from artisan list, a deferred provider that is now conditionally registered is the first suspect.

Debugging resolution problems. composer why-not vendor/package 7.0.0 gives the blocking constraint directly. composer show --all vendor/package lists the available versions and requirements per version — this is the fastest way to confirm whether a v7 exists for the PHP you actually run.

Pin the patch level in the short term. Given this is a fresh major with a one-line changelog, "vendor/package": "7.0.*" (rather than ^7.0) for the first sprint caps your exposure while still accepting fixes. Relax to the caret once the next patch release proves the line is stable.

Extension points. Look for the package's published config's driver/manager/strategy keys and its bound interfaces before subclassing anything. Most Laravel packages of this vintage expose a manager + driver pattern, and swapping a driver via the container is both safer and upgrade-resistant compared with extending a concrete class. If no interface is bound in the container, that is a signal the package expects config-driven customisation only — respect that rather than fighting it.

Record the gap. The changelog for v7.0.0 states intent, not behaviour. Before adopting in production, note what you actually verified (resolution, auto-discovery, config publish, one integration test) in your upgrade ticket. The next release will be reviewed against that baseline, and an unrecorded assumption is one you will re-litigate at the next major.