Laravel Dompdf Laravel Package

Getting Started

v1.0.1 is a compatibility-only patch: the sole documented change is widening the PHP requirement to 8.1+. There are no new APIs, config keys, or deprecations to learn, so onboarding is unchanged from 1.0.0 — but the floor has moved.

Start here, in this order:

1. composer.json — confirm the new constraint ("php": "^8.1" or ">=8.1"). This is the only file that changed behaviourally in this release. Also check the illuminate/* constraints: a PHP bump does not imply new Laravel support.
2. composer.lock / composer why-not — before upgrading existing projects, run composer why-not vendor/package 1.0.1 to see what's holding you back (usually a transitive dependency still pinned to PHP < 8.1).
3. src/*ServiceProvider.php — check whether the provider is auto-discovered (extra.laravel.providers) and what register() vs boot() do. This tells you whether config publishing, facades, or migrations are in play.
4. config/ and README — identify the published config filename and any required env vars before you touch code.

First use case: upgrade an existing 8.1+ project (composer update vendor/package --with-dependencies), then smoke-test the package's primary entry point in php artisan tinker before running the suite. If you were previously held on PHP 8.0, this release is effectively unavailable to you — verify your runtime (php -v, Docker base image, CI matrix) before attempting the bump.

Implementation Patterns

Treat the upgrade as a no-op code change, but a real environment change. For projects already on 8.1+, 1.0.1 should be a drop-in. Run it through the same path you'd use for any patch: update the lock file on a branch, run the full test suite, and deploy to staging before production. Do not bundle a Laravel major upgrade into the same PR — keep the PHP-constraint widening isolated so a rollback is trivial.

Pin the platform in consuming applications. Add config.platform.php to your composer.json so lock files resolve against your actual runtime rather than the CI runner's PHP:

"config": { "platform": { "php": "8.1.0" } }

This prevents a developer on 8.3 from generating a lock file that silently reintroduces syntax your production 8.1 image can't parse.

Wrap the package behind your own thin adapter. Whether it exposes a facade, a contract binding, or plain classes, inject the underlying dependency into one application-level service class rather than calling the facade from controllers and jobs. Patch releases like this one are benign, but the adapter means a future 2.0 swap is a one-file change.

Bind in a service provider, resolve by contract. Where the package publishes a binding, re-bind your implementation in AppServiceProvider::register() (or a dedicated provider) instead of editing anything under vendor/. Register the provider conditionally in config/app.php if you need it disabled in tests.

Exercise it through the framework's fakes. Package-level HTTP, queue, or mail calls should be intercepted with Http::fake(), Queue::fake(), and Mail::fake() in feature tests. If the package ships its own testing helpers (assertions, fake implementations), prefer those — they track the package's own contract and survive internal refactors.

Run a CI matrix across 8.1, 8.2, and 8.3. Now that 8.1 is the declared floor, that version is what the maintainer actually supports; 8.2 and 8.3 will surface any lingering deprecation notices early and cheaply.

Gotchas and Tips

• 8.0 is now excluded. Anywhere still on PHP 8.0 — legacy Docker base images, older Forge/Homestead boxes, self-hosted runners, a forgotten php-8.0 CI lane — will fail at composer install with an unsatisfiable constraint. Grep your infrastructure config before rolling out.
• "Requires PHP 8.1+" is not "supports Laravel 11." The release notes say nothing about framework constraints. Run composer show vendor/package and read the illuminate/support line before assuming compatibility with your Laravel version.
• Deprecation noise on 8.2/8.3. Packages that only just declared 8.1 may still emit notices for dynamic properties or ${var} interpolation. If logs get noisy after the upgrade, set error_reporting to exclude E_DEPRECATED during the transition and file upstream — don't patch vendor/.
• Lock file drift. composer update vendor/package alone can leave transitive constraints stale. Use --with-dependencies, then composer validate and composer audit before committing.
• Config cache staleness. If you publish config for this package, php artisan config:clear (or re-run config:cache) after upgrading; a cached config from the prior version won't reflect new defaults.
• Patch-level signal. 1.0.1 bumping only the PHP constraint is a conservative maintainer move — expect no breaking changes in the 1.0.x line. That also means there is little to gain by rushing the upgrade; schedule it normally.
• Debugging aids: php artisan about for the resolved PHP/Laravel versions, composer show --tree vendor/package for the dependency chain, and composer diagnose when a constraint unexpectedly fails to resolve.
• Extension points to note for later: published config, container bindings, and any package events are where you should customise behaviour. Never subclass vendor classes directly if a binding exists — the latter survives minor upgrades.
• Verify the diff, not just the notes. For a one-line release note, run composer diff vendor/package (or browse the release diff on the repository) to confirm nothing else shifted. Single-line notes occasionally under-report changes.