Weave Code
Laravel Package Tools Laravel Package
beyondcode/laravel-package-tools
Laravel Package Tools streamlines package development with a fluent PackageServiceProvider base class that auto-registers config, migrations, commands, views, translations, routes, and assets. Cut boilerplate and ship Laravel packages faster with less setup code.
Useful tools to help you with your next Laravel package.
Frequently asked questions about Laravel Package Tools
- How do I install beyondcode/laravel-package-tools in a Laravel package?
- Install it with Composer by running composer require beyondcode/laravel-package-tools inside your package directory. Then create a service provider that extends BeyondCode\LaravelPackageTools\PackageServiceProvider and implement the configure(Package $package) method. In that method you call $package->name('my-package') and chain capability methods such as hasConfigFile(), hasMigrations(), hasCommands(), hasViews(), hasTranslations(), hasRoutes(), and hasAssets(). Finally register the provider in your package's composer.json extra.laravel.providers array so Laravel discovers it.
- Which Laravel and PHP versions does laravel-package-tools support?
- The package was last released in March 2019 and predates Laravel 7 through 11 and the PHP 8.x line. Its Composer constraints are stale, so it may block framework upgrades or fail dependency resolution on modern Laravel applications. Treat Laravel 5.x and 6.x era projects as the realistic compatibility window and verify constraints before adopting it. For current Laravel versions, use the maintained spatie/laravel-package-tools successor instead.
- What does the Package class auto-register for my Laravel package?
- The fluent Package object wires up Laravel's native service-provider primitives for you: config merging and publishing, migrations, console commands, Blade views, translations, routes, and public assets. Each capability is enabled by a chainable method such as hasConfigFile(), hasMigrations(), hasViews(), or hasAssets(). It also registers publish groups so your package's files can be exported with artisan vendor:publish. The base class calls your packageRegistered() and packageBooted() hooks so you can add custom logic at the right lifecycle point.
- Why does my package name have to be declared first in the laravel-package-tools chain?
- The Package object derives default paths and publish tags from name(), so name() must be the first call in configure(). If you call hasViews() or hasMigrations() before name(), those methods compute paths from an unset package name and fail at runtime rather than during code review. The same issue appears if you rename a package without updating the name() call. Put name() first and treat it as an immutable identifier.
- How do I test a Laravel package built with laravel-package-tools?
- Use Orchestra Testbench to boot a minimal Laravel application around your package's service provider. Register your provider in the Testbench getPackageProviders() array, then assert that config, migrations, views, routes, and commands are registered as expected. Because this package is archived, pin your test matrix to the Laravel and PHP versions you actually support and avoid relying on upstream fixes. Add a smoke test that runs the provider's boot path to catch ordering mistakes such as name() being declared too late.
- Is beyondcode/laravel-package-tools still maintained?
- No. The GitHub repository is archived, the last release was 2019-03-05, and it has no maintainer, release cadence, or security-response process. It has roughly 74 stars and zero dependents, so there is no upstream patch path and no ecosystem signal. Supply-chain policies that block archived dependencies on a production boot path should flag it. The MIT license means obligations are effectively limited to retaining the notice.
- What is the maintained alternative to beyondcode/laravel-package-tools?
- spatie/laravel-package-tools is the actively maintained, conceptually aligned successor with a similar fluent Package API. It supports current Laravel and PHP releases and is the usual drop-in choice for new package work. Migration is typically tens of lines of diff per service provider because the API surface is close. Confirm that its configuration methods cover any custom publish tags or path conventions you rely on.
- Can I use laravel-package-tools in a single Laravel application instead of a package?
- You can, but it adds little value. The library is a developer-ergonomics layer for authors of reusable packages, not an application feature. In a single app that only consumes third-party packages, Laravel's own service-provider methods already cover config, migrations, views, routes, and commands. Adopt it only when your roadmap involves repeated first-party package authorship, such as internal domain packages, SDKs, modular-monolith extraction, or a partner plugin SDK.
- What are the production risks of depending on an archived Laravel package?
- The code performs no I/O and no network access, so direct exploit surface is minimal. The real exposure is upgrade breakage: Laravel majors changing publish-group and migration-registration semantics, PHP 8.x deprecation noise, stale Composer constraints, and dependency-review gates flagging an abandoned dependency. Because the base class sits on the boot path of every package that extends it, a single framework upgrade can force a simultaneous migration across all dependent packages. Decide the exit path before package count and coupling grow.
- How do I migrate a service provider off laravel-package-tools?
- Replace the PackageServiceProvider base class with Laravel's Illuminate\Support\ServiceProvider and move each fluent call into the equivalent native method: mergeConfigFrom() and publishes() for config, loadMigrationsFrom() for migrations, loadViewsFrom() and publishes() for views, loadTranslationsFrom() for translations, loadRoutesFrom() for routes, commands() for commands, and publishes() for assets. Preserve any custom publish tags and path conventions your consumers rely on. Keep the packageRegistered() and packageBooted() logic in register() and boot() respectively, and run your existing Testbench suite to confirm parity.
Weaver
How can I help you explore Laravel packages today?