Laravel Svelte Preset Laravel Package

Getting Started

This release (v0.2.1) is a compatibility release, not a feature release. Its substance is a widened support matrix: Laravel 9 and PHP 8 are now supported, plus CI housekeeping. That tells you the package is still pre-1.0 and stabilising, so treat the install as the first thing to validate rather than the last.

1. Confirm your own versions line up. The headline change is Laravel 9 / PHP 8 support. If you are on Laravel 9, this is the first version of the package you can install at all — the constraint change in composer.json is the actual deliverable here. Run composer why-not vendor/package ^0.2 to see exactly which constraint was previously blocking you.
2. Install and let auto-discovery work. composer require vendor/package:^0.2.1. Laravel's package discovery should register the service provider; check php artisan about or composer show vendor/package if you need to confirm what was registered.
3. Look first at the README's config/migration publishing step. Pre-1.0 packages almost always require php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" (or a tag) before anything works. This is the single most common reason a fresh install "does nothing".
4. First use case. Boot a throwaway route or php artisan tinker session and exercise the package's primary entry point — a facade call, a model, a command — against a scratch SQLite database. Do this before wiring it into an existing app, because PHP 8 and Laravel 9 support being new means the happy path is the only path with meaningful test coverage.
5. Read the changelog backwards. There is no prior assessment on record, so v0.2.1 is your baseline. Check the repo's release history for v0.2.0 and below to understand what the package actually does and how volatile its API has been.

Implementation Patterns

Pin the minor version, not the patch. For a 0.x package, SemVer permits breaking changes in the minor position. ^0.2.1 is the right constraint; ^0.2 is defensible if you trust the maintainer; * or dev-main is not. Commit composer.lock and let Renovate/Dependabot surface the next 0.x bump as a reviewable PR rather than a silent composer update.

Treat Laravel 9 / PHP 8 support as an untested claim until you test it. A support-matrix bump plus "update GitHub Actions" is a strong signal the maintainers added the CI job in this release. That means the combination was likely green in CI for the first time days ago. Add one integration test in your own suite that touches the package's main code path, running on your actual PHP and Laravel versions. This is cheap and it is your only real guarantee.

Wrap the package behind your own boundary. Pre-1.0 packages churn. Define a thin interface or a small service class in your app that calls the package, and inject that everywhere. When v0.3.0 renames a method, you edit one file. This costs an hour now and saves a scattered find-and-replace later.

Isolate config in config/. Publish the package config, then override only what you need and let the rest inherit. Avoid editing the published file into something unrecognisable — future versions ship new keys with defaults, and a heavily mutated config file makes upgrade diffs unreadable.

Keep the package's migrations separate from your app's. If it ships migrations, leave them in the vendor publish path rather than copying them into database/migrations. Copied migrations become orphaned from the package's schema changes and you inherit the maintenance burden.

Version-gate in CI. If you maintain multiple apps on different Laravel versions (8 and 9, say), add a matrix job per app rather than assuming one lockfile covers both. The package now claims both are supported; prove it in the app that actually runs the older one.

Watch the CI workflow change. "Update Github Actions" often means deprecated action versions were bumped. That is irrelevant to your runtime, but if you fork the package or vendor it, re-run its test suite locally on PHP 8 before trusting your fork.

Gotchas and Tips

• The constraint bump may not be the only change. "Add support for Laravel 9" frequently requires real code edits — Str/Arr helper moves, removal of ->getKeyName() assumptions, illuminate/support facade signature changes, or dropped assertTimesSent-style test APIs. Read the diff between v0.2.0 and v0.2.1, not just the release notes. If there is no code diff, the package was probably already compatible and only the composer constraint was relaxed — which is good news, but confirm it.
• PHP 8 deprecations surface as noise, not errors. Dynamic properties, passing null to non-nullable internal parameters, and implicit float-to-int conversions now emit Deprecated notices. If your error handler converts notices to exceptions (several packages and Sentry configs do), a package that "supports PHP 8" can still break your request cycle. Run your suite with error_reporting(E_ALL) once after upgrading.
• Laravel 9 dropped several things the package may still reference. The assertTimesSent mail fake, Illuminate\Support\Str::of edge cases, the old ->sendNow() signature, and Symfony Mailer's older API all changed. If the package touches mail, notifications, or queues, test those paths specifically — they are the usual casualties and are rarely covered by a smoke test.
• Debugging: start with the container. If the package misbehaves, app()->make(...) the provider's bindings directly in Tinker to see whether the failure is in registration or in your usage. Nine times out of ten with a newly-compatible package it is a stale cached config — run php artisan config:clear && php artisan cache:clear before you debug anything else.
• Extension points are likely still moving. At 0.x, published config keys, event names, and manager/extender classes are all fair game for renaming. Before you build on an extension point (custom driver, custom resolver, event listener), check whether it appears in the package's own tests. Untested extension points are the ones that break silently between minors.
• Do not adopt a 0.x package as load-bearing infrastructure without an exit plan. If it sits on a critical path, note how you would replace it: how many call sites, how much of its data model you own. The v0.2.1 notes suggest an actively maintained but young project; that is fine, provided you know your escape route.
• Re-check docs for the version you installed. README examples on the default branch often target unreleased code. Confirm the docs you are reading correspond to the v0.2.1 tag, especially for anything involving Laravel 9-only APIs.
• Record the baseline. Since this is the first assessment, pin the date, the installed version, and the PHP/Laravel versions you validated against. The next release note will be much easier to judge against a written record than against memory.