Laravel Package Tools Laravel Package

Product Decisions This Supports

• Build vs. buy for package infrastructure. The "build" option here is a bespoke base service provider in every internal package — duplicated config merging, migration publishing, asset publishing, route registration, and translation loading. This package replaces that with a single inherited PackageServiceProvider, so the decision collapses to "adopt a ~free MIT dependency" versus "own and maintain boilerplate across N packages." For most teams the latter is pure cost with no differentiation.
• Standardizing an internal package portfolio. Because the package is opinionated about directory layout (src/, config/, database/migrations, resources/views, routes/), adopting it is effectively a decision to standardize how all first-party packages are structured. That is a roadmap-level decision: it lowers onboarding time, makes packages portable between teams, and makes audits predictable.
• Deciding whether to extract functionality into a distributable package at all. When a feature is a candidate for reuse across products (auth add-on, billing module, admin toolkit, white-label layer), the cost of packaging it drops materially — publishing config, migrations, assets, views, translations, and commands becomes declarative rather than engineering work. This shifts the roadmap conversation from "is packaging worth it?" to "which modules deserve to be packages?"
• End-user install experience as a product requirement. The built-in InstallCommand (publishConfigFile(), publishAssets(), publishMigrations(), copyAndRegisterServiceProviderInApp()) lets a package ship as a single php artisan …:install step instead of a README with six vendor:publish commands. That is a support-ticket and activation-rate decision, not just an engineering nicety.
• Ecosystem and partner strategy. If the roadmap includes third-party developers, integrators, or a plugin marketplace, this is the substrate for a consistent plugin contract: predictable publish tags, predictable config file names, predictable migration handling. It makes "here is how you build against us" a documentable standard rather than a bespoke conversation per partner.
• Migration and upgrade policy for consuming applications. runsMigrations() (load migrations without publishing) versus publish-then-own is a real product decision about how much control customers have over schema changes. This package lets you choose per package and change later without rewriting provider code.
• Roadmap sequencing for multi-product organizations. A shared package layer (SDK, shared domain models, UI kit) is usually a prerequisite for launching a second product or a self-hosted/on-prem edition. This package is the cheapest enabler of that prerequisite.

When to Consider This Package

Adopt when most of the following are true:

• The team is on Laravel/PHP and intends to remain so for the planning horizon; this is framework-specific tooling with no value outside Laravel.
• There are two or more first-party packages, or a credible near-term plan for a second. For a single package, the boilerplate it removes is small enough that the dependency may not pay for itself.
• You want convention over configuration: the team is willing to accept Spatie's directory layout (or already matches it via package-skeleton-laravel) rather than defend a custom structure.
• Packages need to ship publishable surface area — config, migrations, assets, views, translations, Inertia/Blade components — and you want a uniform vendor:publish --tag=… contract.
• You want a turnkey installer command without writing one from scratch.
• Licensing is acceptable. MIT is compatible with essentially any commercial product; no copyleft exposure and no procurement cycle.
• Supply-chain tolerance fits. Note that consuming applications typically inherit this as a transitive runtime dependency of your packages, so it enters customers' dependency graphs — a small but real consideration for enterprise or regulated buyers who scrutinize dependency trees.

Look elsewhere or defer when:

• The work is a single application, not a package. Laravel's own service provider APIs plus a few lines of code cover it; the abstraction adds indirection without return.
• You need a framework-agnostic or non-Laravel distribution target — Symfony bundles, standalone SDKs, or multi-framework plugins.
• You have an established internal package template with different conventions. The opinionated layout is the value proposition; fighting it removes the benefit and leaves you with a dependency you are working around.
• You need capabilities beyond registration and publishing — versioned package discovery, marketplace metadata, licensing/entitlement enforcement, automated upgrade paths. This package is scaffolding, not a distribution platform; those need separate tooling.
• Dependency minimalism is a hard constraint (very large monorepos with strict vendor budgets, or buyers with allowlists requiring per-dependency review). Here the boilerplate is genuinely cheap and you should just write it.
• Data-quality caveat worth resolving before committing: the "0 dependents" figure in the source metadata almost certainly understates reality — this package is a dependency of a large number of widely used Spatie packages. Treat the star count and dependent count as unreliable signals and verify adoption by checking the packages your team already installs.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a small, free, MIT-licensed developer tool that removes repetitive setup work from every Laravel package we build. It does not ship a customer-facing feature; it lowers the cost and risk of building reusable modules, which is the prerequisite for launching additional products, a partner/plugin program, or a self-hosted edition without duplicating the codebase. It is a dev-time dependency from Spatie, one of the most established names in the Laravel ecosystem, with tagged releases and a changelog. The realistic ask is roughly one engineer-day to adopt and document, and the downside is bounded: it is a thin abstraction, so removing it later means inlining boilerplate rather than unwinding an architecture.

For engineering leadership — the substance: We inherit PackageServiceProvider and declare package surface area in one configurePackage() method: config files, views, translations, assets, routes, migrations, Blade and Inertia components, view composers, commands, and publishable example service providers. It gives us a single InstallCommand builder so each package ships a one-command install instead of a multi-step README. Migrations can be publish-and-own or auto-loaded via runsMigrations(), so we control how much schema authority customers get. It is opinionated about directory structure and pairs with Spatie's package skeleton, so the real commitment is adopting that structure as our internal standard. It is PHP/Laravel-only, so it locks us no further than we are already locked, and it becomes a transitive dependency in consuming applications — worth flagging to any enterprise buyers who review dependency trees.

For the product team: the practical win is that "should this be a reusable package?" becomes a cheap question to answer, and package installation becomes a supportable, one-step customer experience rather than a documented ritual that generates tickets.