Laravel Package Tools Laravel Package

Technical Evaluation

Architecture fit. spatie/laravel-package-tools is a build-time/runtime base class for package authors, not an application feature library. It supplies an abstract PackageServiceProvider plus a fluent Package configuration object that centralizes registration of config files, views, view components, migrations, routes, commands, translations, assets, Inertia components, publishable service providers, install commands, and lifecycle hooks. The fit question is therefore organizational, not application-level: it pays off only if we build and maintain reusable Laravel packages internally (domain modules, shared SDKs, tenant/feature packages) rather than a single monolith. Notably, it is a production dependency of each package (the provider ships in the package), so it lands in every consuming app's vendor/ — this is not a dev-only tool like PHPUnit.

Integration feasibility. High. Adoption is a composer require plus extending the base provider and replacing hand-rolled register()/boot() boilerplate with fluent calls. The package is explicitly opinionated about directory layout (config/, database/migrations/, resources/views/, resources/dist/, routes/) and about path resolution being relative to src/ (e.g. ../ConfigFiles), so porting existing packages is mechanical but not zero-effort — expect a few hours per package plus verification of publish tags.

Technical risk.

• Blast radius: a major-version change touches every internal package simultaneously. Single upgrade event, many repos.
• Implicit behavior: registration and publishing happen under the hood via lifecycle hooks; when a file "just doesn't publish," diagnosis requires reading vendor code. Silent no-ops from wrong relative paths are the most likely support ticket.
• Naming collisions: publish tags derive from the package name (with a laravel- prefix stripped), so naming discipline across packages is a real constraint.
• Supply chain / support: MIT, single-vendor OSS with no SLA. License is fine; support is community GitHub issues only.
• Data quality flag: the reported dependents: 0 is almost certainly an artifact — this package is a transitive dependency of a large share of Spatie's ecosystem and of most teams already using Spatie packages. Validate via Packagist reverse dependencies before treating "low adoption" as a risk signal.

Key questions.

1. How many internal packages/providers do we actually maintain today, and how many will exist in 12 months? (Threshold: ≥3 makes standardization worthwhile.)
2. Are we already consuming it transitively via other Spatie packages, and at which pinned version? That constrains our floor.
3. Which Laravel/PHP versions must we support across the planning horizon, and does the package's support matrix cover all of them?
4. Who owns major-version upgrades, and is there a defined window (e.g. within one minor cycle of a Laravel major)?
5. Do we need the higher-touch features (install command, copyAndRegisterServiceProviderInApp, publishable providers) or only config/views/migrations/routes?
6. What is our policy for unpinned third-party code in runtime dependencies versus build tooling?

Integration Approach

Stack fit. Composer-based Laravel packages across Laravel 9–12 / PHP 8.x (confirm exact matrix from composer.json, not the README). Distribution method is irrelevant — Packagist, private registry, or path/VCS repositories all work. It composes cleanly with existing conventions and does not force a DI or architecture pattern; it only standardizes registration.

Migration path.

1. Inventory every ServiceProvider in internal packages and classify calls into "covered by the fluent API" vs "bespoke logic to keep in register()/boot()."
2. Pilot on one low-risk package; port the provider; retain uncovered logic in overridden register()/boot().
3. Validate the full publish surface in a staging app (vendor:publish --tag=<name>-config|views|migrations|assets), plus runsMigrations() vs publish-then-migrate behavior.
4. Codify the pattern in an internal skeleton derived from spatie/package-skeleton-laravel so new packages start compliant.
5. Roll out per package, deprecating hand-rolled providers as each is touched.

Compatibility. Pin ^X.Y per package via a shared constraint in the monorepo or a documented standard; add a CI job asserting the constraint resolves against the oldest and newest supported Laravel majors. Because the library is a runtime dependency, version skew across packages will surface as conflicting constraints in consuming apps — keep all internal packages on the same major.

Sequencing. (a) Validate support matrix and reverse-dependency reality → (b) internal skeleton + written convention → (c) pilot package → (d) shared publish-tag naming scheme to prevent collisions → (e) CI template (test matrix + publish smoke test) → (f) bulk migration → (g) scheduled major-upgrade rehearsal.

Operational Impact

Maintenance. Low steady-state cost: the library abstracts boilerplate we would otherwise hand-write. The real recurring cost is major-version upgrades aligned to Laravel majors, plus convention drift if teams fork or partially adopt. Budget one focused upgrade task per Laravel major, not continuous maintenance.

Support. Community-only: GitHub issues, changelog, releases; no vendor SLA. Mitigations: pin versions, vendor the constraint centrally, and note that MIT + a bounded, mechanical surface means the exit cost is low — worst case, drop the base class and hand-roll providers (a known, scoped effort, roughly the same as the original port).

Scaling. Value scales with package count: more packages means more consistency gain (uniform publish tags, uniform install UX, faster new-package bootstrap) and fewer bespoke onboarding docs. Runtime cost is limited to provider boot work — negligible for normal apps, but worth a look if we run Octane or long-lived workers and do anything non-trivial in boot() or rely on config merging with config:cache.

Failure modes to monitor.

• Duplicate/conflicting registration when a provider both extends the base class and registers the same resource manually → boot-order and "double-published" surprises.
• Silent no-op publishing from incorrect relative paths — enforce a publish smoke test in CI, not manual QA.
• Migration duplication when both runsMigrations() and published migrations are in play.
• Publish-tag collisions when package names are too similar or already carry a laravel- prefix.
• Install commands that write to the app (copyAndRegisterServiceProviderInApp) breaking unattended CI or re-runs — gate these behind interactive use.
• Cross-package version skew on the shared major, which manifests as consumer-side composer conflicts rather than package-side test failures.

Ramp-up. A Laravel-fluent engineer is productive in well under a day; the learning curve is the directory convention and publish semantics, not the API. Plan a short internal guide, the skeleton repo, and one reference implementation. Total organizational ramp is effectively one sprint for the pilot plus one package per engineer-day thereafter.

TPM recommendation. Adopt as a Tier-3 internal standard with a pinned major, an internal skeleton, and a publish smoke test in CI — contingent on confirming (1) the Laravel support matrix, (2) that we maintain enough packages to justify the convention, and (3) that the dependents: 0 figure is the data artifact it appears to be. Do not adopt the install-command/publishable-provider features until the config/views/migrations/routes core is proven.