Upgrade guide

The toolkit follows Semantic Versioning, and the promise worth holding it to is the one below the top number: nothing but a major release breaks working code. Minor releases add functionality. A patch release occasionally does too, where the addition closes a gap rather than opening a new surface — 2.4.1's asset discovery gave hasAssets() the file discovery every other hasX() already had, and a package that named its entries never notices. Major releases may break.

To 2.4.2 #

Nothing to do. Two additions and one correction, none of which changes what a package already renders.

The three tag directives take no package name. @packageAssets, @packageStyles and @packageScripts with no argument render every package that declared entries. @packageAssets('blog') renders byte for byte what it did, so this is only worth adopting where the layout is the application's own — that is the line that otherwise has to be edited every time a package is installed or removed. @packageAssetUrl still takes both arguments.

hasAssetFallback() says where to serve a shipped file from when nothing is published. Worth declaring if your package already serves its assets from a route of its own and you support deployments where public/ cannot be written — a read-only container, Vapor, shared hosting. There, an entry used to render no tag at all, and a page lost its stylesheet or its behaviour with nothing to say why. Every other package is unaffected: the resolver is reached only after both the mirror and public/vendor/{short-name} came back empty.

resolution() stops reporting shipped for a copy that can never be written. A mirrored package — the default — claimed shipped for every entry outright, so an unwritable public/ looked healthy in php artisan about while the page rendered nothing. It now says fallback, or not published where there is no fallback either. Nothing else moves: an entry the lazy mirror simply has not reached yet, which is every entry on a fresh install, still reports shipped.

To 2.4.1 #

Nothing to do. One thing starts working that previously did nothing: hasAssets() with no entries named now discovers them, instead of leaving @packageAssets with nothing to render.

A package that already names its entries is untouched — naming any entry replaces discovery outright. A package that called hasAssets() bare gets the stylesheets and scripts from the asset directory's root and its css/ and js/ subdirectories, which is what a template asking for @packageAssets wanted in the first place. The two cases discovery cannot read off a directory listing still need naming: a code-split build, whose chunk directory is deliberately skipped, and an IIFE or UMD bundle, since a discovered script is emitted as a module.

To 2.4 #

Purely additive. Update the constraint and run composer update:

{
    "require": {
        "nyoncode/laravel-package-toolkit": "^2.4" 
    }
}
{
    "require": {
        "nyoncode/laravel-package-toolkit": "^2.4" // [tl! ++]
    }
}

What is new #

hasBroadcastChannels() registers channel authorization files with the broadcaster. If you were passing a channel file to hasRoutes() — the only option before — move it:

$packager
    ->hasRoutes()                                  
    ->hasRoutes(['web.php', 'api.php'])            
    ->hasBroadcastChannels(['channels.php']);      
$packager
    ->hasRoutes()                                  // [tl! --]
    ->hasRoutes(['web.php', 'api.php'])            // [tl! ++]
    ->hasBroadcastChannels(['channels.php']);      // [tl! ++]

The old arrangement kept working, but it loaded the authorization callbacks inside a route group and put your channel names into the router. Both defaults point at ../routes, so name the files explicitly or move channels to their own directory.

hasSeeders(), hasFactories() and hasStubs() add three publish-only resources, with the tags blog::seeders, blog::factories and blog::stubs.

The install command gained publishSeeders(), publishFactories() and publishStubs(), all three included in publishEverything().

PublishedAssets::flush() clears the resolved URLs and per-request sync marks, for applications running the toolkit under a long-lived worker.

To 2.3 #

Additive, with one behaviour change worth knowing about.

Assets now also publish under laravel-assets #

In addition to {short-name}::assets. That tag is what the Laravel application skeleton runs from Composer's post-update-cmd, so your assets are republished after every composer update in an application that keeps the default script — the same mechanism Horizon and Telescope rely on.

Laravel accumulates publish groups per path, so both tags publish the same files and an untagged vendor:publish is unaffected. No action needed, but be aware that a consumer's composer update may now overwrite hand-edited files under public/vendor/{short-name} — that hook runs with --force.

The asset mirror #

Support\PublishedAssets keeps public/vendor/{short-name} in step with your dist/ directory without anyone running a command. It is registered automatically by hasAssets(); opt out with:

$packager->hasAssets(mirror: false);
$packager->hasAssets(mirror: false);

To 2.2 #

Additive: events, optimize commands and the configurable publish tag separator.

To 2.1.1 #

A bug-fix release, but several of the fixes changed behaviour that was previously broken — so something in your package may start working, and a workaround you wrote may become redundant.

Renamed #

bootVewComposers() → bootViewComposers(). The misspelling is kept as a deprecated alias; if you override it, move to the correct spelling.

Deprecated #

Contracts\HasAbout will be removed in 3.0. Packable already declares aboutData(), and ProvidesPackageServices extends Packable, so PackageServiceProvider covers it:

class BlogServiceProvider extends PackageServiceProvider implements HasAbout 
class BlogServiceProvider extends PackageServiceProvider implements Packable 
class BlogServiceProvider extends PackageServiceProvider implements HasAbout // [tl! --]
class BlogServiceProvider extends PackageServiceProvider implements Packable // [tl! ++]

To 2.1 #

Laravel 10 and 11 support was removed. The requirement is now Laravel 12 (>= 12.61.1) or 13 (>= 13.12.0).

Both branches had passed security-support end of life, and the June 2026 advisories — including the High-severity CRLF injection CVE-2026-48019 — were patched only in Laravel 12.60+ and 13.9+, never backported. There is no secure release on those branches, so the minimums are pinned to the first patched versions.

{
    "require": {
        "nyoncode/laravel-package-toolkit": "^2.1"
    }
}
{
    "require": {
        "nyoncode/laravel-package-toolkit": "^2.1"
    }
}

No code changes are required. If your package must still support Laravel 10 or 11, stay on ~2.0.0 — and consider what that implies for the applications installing it.

To 2.0 from 1.x #

{
    "require": {
        "php": "^8.2",
        "nyoncode/laravel-package-toolkit": "^2.0"
    }
}
{
    "require": {
        "php": "^8.2",
        "nyoncode/laravel-package-toolkit": "^2.0"
    }
}

Then composer update. No code changes are required unless your package explicitly depends on Laravel 9 or PHP 8.1.

Timeless migrations, in detail #

The addition is non-breaking, but it changes what happens when a migration file has no date prefix. Before 2.0 such a file was published verbatim, which produced a migration Laravel could not order. From 2.0, the toolkit detects the missing prefix and generates one at publish time.

If your package ships migrations with a date prefix, nothing changes. If it shipped prefix-less files and you worked around the ordering by hand, you can drop the workaround.

Compatibility promise #

• Major versions may contain breaking changes.
• Minor versions stay backward compatible within a major.
• Patch versions contain bug fixes and security updates only.

Recommended constraint:

{
    "require": {
        "nyoncode/laravel-package-toolkit": "^2.4"
    }
}
{
    "require": {
        "nyoncode/laravel-package-toolkit": "^2.4"
    }
}

Looking ahead to 3.0 #

Known removals:

• Contracts\HasAbout — use Packable.
• bootVewComposers() — use bootViewComposers().

One rule holds the whole plan for 3.0 together: nothing gets taken away without a replacement that is already in place.