Advanced Logger Laravel Package

Getting Started

This is a Laravel-version-locked release: v7.0.0 is the first line targeting Laravel 7, following the same major-version convention as Laravel itself. Treat it as a compatibility baseline, not a feature release.

1. Confirm your framework version. v7.0.0 is intended for Laravel 7 applications. Check composer.json for laravel/framework: ^7.0 and PHP ^7.2.5 or higher before installing.
2. Install the package at the matching major:

   composer require <vendor>/<package>:^7.0
   

   Do not use a floating constraint such as * or dev-master; the entire point of this release is that the package major tracks the framework major.
3. Look first at the package’s README, CHANGELOG, and upgrade notes. Because this is primarily a framework-compatibility release, the most important information is whether the public API changed and whether Laravel 6 is still supported.
4. Run the standard Laravel package setup steps if the package ships them:

   php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider"
   php artisan migrate
   php artisan config:clear
   

5. First use case: wire the package into a single route or controller and run a smoke test before adopting it across the application. For a Laravel 7 app, a feature test using RefreshDatabase and the package’s primary entry point is usually enough to confirm the integration.

If you are still on Laravel 6, stop here. The v7 release line is not intended as a drop-in for Laravel 6 applications.

Implementation Patterns

Version-lockstep dependency management

Keep the package major aligned with the framework major in composer.json:

{
  "require": {
    "php": "^7.2.5",
    "laravel/framework": "^7.0",
    "<vendor>/<package": "^7.0"
  }
}

Avoid constraints that span major versions unless the package explicitly documents support for both:

"<vendor>/<package": "^6.0 || ^7.0"

The release note says this is the first release for Laravel 7; it does not claim continued Laravel 6 support. Assume v7 is Laravel 7+.

Upgrade workflow from a previous major

Use a dedicated branch and let Composer resolve the whole dependency graph:

git checkout -b upgrade/package-v7
composer require <vendor>/<package>:^7.0 --with-dependencies
php artisan config:clear
php artisan route:clear
php artisan view:clear
composer dump-autoload
php artisan test

Run the application’s full test suite, not just package-specific tests. A framework-major package release can surface indirect incompatibilities through shared Illuminate dependencies.

CI matrix per Laravel version

If the application or a downstream package must support multiple Laravel versions, encode that in CI rather than in a single permissive Composer constraint:

matrix:
  laravel: ["^6.0", "^7.0"]
  include:
    - laravel: "^6.0"
      package: "^6.0"
    - laravel: "^7.0"
      package: "^7.0"

This keeps each job on a coherent set of framework and package versions.

Service provider and config integration

Most Laravel packages auto-discover their service provider. Verify discovery after upgrading:

php artisan package:discover

If the package is not auto-discovered, register it manually in config/app.php. Publish and review the config file before changing behavior; prefer environment variables over editing vendor defaults.

Feature-test the integration point

Use Laravel 7’s testing helpers to verify the package behaves correctly in your application context:

public function test_package_integration(): void
{
    $this->artisan('package:command')->assertExitCode(0);
}

If the package performs HTTP calls, queues jobs, or dispatches events, use Http::fake(), Queue::fake(), and Event::fake() in tests to isolate the package boundary.

Gotchas and Tips

• The main breaking change is the framework constraint, not necessarily the public API. v7.0.0 may contain no application-facing code changes, but Composer will refuse to install it alongside Laravel 6. Plan the framework upgrade and package upgrade together.
• Do not infer full backward compatibility from a major version bump. The release note only states that this is the first Laravel 7 release. Check the changelog for removed methods, changed config keys, or renamed classes before upgrading production code.
• Clear Laravel’s caches after upgrading. Stale package manifests and cached config are common sources of “class not found” or “provider not registered” errors:

  php artisan optimize:clear
  composer dump-autoload
  

• Diagnose dependency conflicts with Composer’s dependency tools:

  composer why-not <vendor>/<package> 7.0.0
  composer show --tree <vendor>/<package>
  

  This quickly reveals whether another package is pinning an older Illuminate version.
• Check bootstrap/cache/packages.php if auto-discovery behaves unexpectedly. Removing the cached manifest and re-running php artisan package:discover resolves most discovery issues.
• Pin production installs to the lock file. After upgrading, commit composer.lock so deployments do not resolve a different v7 patch release unexpectedly.
• Watch transitive Illuminate dependencies. A package may require illuminate/support: ^7.0 while another dependency still requires ^6.0. Composer will usually catch this, but it is the most common upgrade blocker.
• Use the config file as the primary extension point. Publish it, review every option, and override via environment variables where possible. Avoid editing files under vendor/.
• If the package exposes events, bindings, or macros, test those explicitly after the upgrade. Framework-major releases can change container resolution or event ordering in ways that a simple install smoke test will not catch.
• Keep an eye on patch releases in the v7 line. Because this is the first Laravel 7 release, early v7.x patches are likely to contain compatibility fixes; review them before locking a long-lived production version.