Wechat Work Push Laravel Package

Getting Started

Release 2.0.0 is a compatibility gate, not a feature release. Two things are stated: the package now supports Laravel 9, and it no longer supports anything below Laravel 9. Treat the major version bump as a hard platform requirement rather than an optional upgrade.

Practical floor implied by the change: Laravel ^9.0 and PHP >=8.0.2 (Laravel 9's own minimum). If your app is still on Laravel 6/7/8, you cannot adopt 2.0.0 at all — you stay on the 1.x line, which is now effectively frozen.

Where to look first:

1. composer.json — the require block is the real contract here. Confirm the illuminate/* or laravel/framework constraint is ^9.0 (or ^9.0|^10.0 if the constraint is open-ended) before assuming anything about Laravel 10/11 compatibility.
2. The repository's UPGRADE.md / CHANGELOG.md and the v1.x..v2.0.0 diff. The release note only mentions the framework floor, so any API changes in this major are undocumented — the diff is your only source of truth.
3. The service provider's register()/boot() — check whether config publishing tags or config keys were renamed as part of the Laravel 9 alignment.

First use case: install on a throwaway Laravel 9 skeleton before touching your real application.

composer require vendor/package:^2.0
php artisan about          # confirm framework + package discovery
php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"

Then exercise the one thing the package actually does — a route, a command, a queue job, a facade call — and confirm it works on 9.x. That smoke test is worth more than reading the release note.

Implementation Patterns

Gate the constraint, don't fork the code. If you maintain multiple applications on different Laravel versions, express the difference in composer.json, not in if (version_compare(app()->version(), ...)) branches:

{ "require": { "vendor/package": "^2.0" } }

Laravel 9 → ^2.0; Laravel 8 → ^1.0. Keep the two application branches on separate majors rather than trying to write version-agnostic glue.

Bump and diagnose in one move. The most common failure mode is composer update resolving to v1 because something else pins Laravel 8. Find the blocker explicitly instead of reading solver output:

composer why-not vendor/package 2.0.0
composer update vendor/package --with-dependencies

Republish and diff published assets. If v1 published a config file, migration, or view, the Laravel 9 release may have changed defaults. Publish to a temp path and diff rather than blindly --force:

php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --force
git diff config/package.php

Update CI in the same PR as the constraint. Drop the Laravel 8 / PHP 7.4 matrix jobs and add 9.x. A package that requires PHP 8 will fail on a stale php-version: 7.4 matrix in a way that looks like a package bug.

Verify auto-discovery explicitly. Laravel 9 changed package manifest handling around discovery; if the provider isn't loading, check bootstrap/cache/packages.php and consider an explicit registration while debugging.

Gotchas and Tips

• "Supports Laravel 9" is not "supports Laravel 10/11." Unless the constraint is ^9.0|^10.0, do not assume forward compatibility. Read the require line, not the release note.
• The 1.x line is now a dead end. No stated backports. Plan the Laravel 8 → 9 application upgrade as part of, or before, the package upgrade; don't sit on v1 expecting fixes.
• Laravel 9's underlying swaps bite wrapper packages. Laravel 9 moved to Symfony Mailer, Flysystem 3, and dropped Doctrine DBAL. If this package wraps mail, filesystem, or schema operations, test those paths specifically — the framework change, not the package, is what breaks.
• Migrations are the most likely silent breakage. Doctrine DBAL removal means ->change() on columns behaves differently, and Laravel 9's anonymous migration classes (return new class extends Migration) can collide with old published migrations that used named classes. Run php artisan migrate:fresh on a scratch database.
• Config cache masks publish problems. php artisan config:clear && php artisan cache:clear before concluding a config key was renamed.
• Missing changelog is itself a finding. The release note documents nothing beyond the framework floor. Before upgrading production, scan the diff for removed/renamed public methods, facades, and config keys — a major version with a one-line changelog deserves that manual review.
• Pin exactly during rollout. "vendor/package": "2.0.*" while stabilising, loosen to ^2.0 once you've verified the integration paths.