Skeleton Laravel Package

Product Decisions This Supports

Build vs. buy for internal package boilerplate. This package is a scaffold, not a runtime dependency — it answers "do we start every reusable Laravel package from a blank directory or from an opinionated template?" That is a developer-productivity decision, not a customer-facing feature decision, and should be evaluated against the cost of your team writing its own starter kit (typically 1–2 engineer-days plus recurring drift).

Standardising package conventions across the org. The concrete conventions on offer — PSR-4 autoloading, auto-discovered service provider, publishable config, publish tags, a test stub — are the things that make internal packages predictable to consume. If your apps have three different ways of registering package config, this package is the argument for picking one.

Roadmap input for platform / DevEx work. Adoption here is a signal to sequence an internal "package starter kit" roadmap item: documented conventions, a CI check for config parity, and an upgrade runbook. It does not justify a standalone platform investment on its own.

Extraction use case. Supports the recurring decision "should this domain logic (billing, notifications, entitlements) live in the monolith or move to a shared package?" by lowering the marginal cost of the 'extract' option.

Positioning caveat that affects product framing. The supplied material describes this both as a "Laravel UI component package" and as a "lightweight Laravel package scaffold." Those are different products with different buyers. Until that ambiguity is resolved, treat it strictly as scaffolding and do not plan any UI/component-library roadmap on top of it.

When to Consider This Package

Adopt when:

• You are a Laravel shop shipping reusable internal packages at a cadence of roughly two or more per year.
• You currently lack a written convention for package layout, config publishing, or service provider registration, and the inconsistency is costing real onboarding time.
• You are comfortable treating the scaffold as source you copy and own, not a dependency you upgrade. This is the correct consumption model for a skeleton and it neutralises most of the maintainer-risk concern.
• You need only the basics: autoloading, provider, config, tests, migrations/routes/views placeholders.

Look elsewhere when:

• You need actual UI components. This is not that, despite the description field.
• You need a maintained runtime library. This is a 1.0.x scaffold with 0 stars and one visible patch release; it has no community validation and no evidence of release cadence.
• You need richer scaffolding: queued jobs, queueable test harnesses, multi-version Laravel CI matrices, static analysis, or upgrade documentation. Established community package skeletons cover those and have the release hygiene to match.
• You support older Laravel versions in your estate — verify the package's framework constraints before assuming coverage.
• You will build exactly one package. The overhead of adopting a template exceeds the boilerplate it saves.

Treat the v1.0.1 release as a data point, not a defect. The only shipped change is a config filename rename to an sb- prefix — a collision-avoidance fix that a stricter release process would have caught before 1.0.0. The convention is right; the timing tells you this is early-stabilisation. Plan to read changelogs rather than auto-bump.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're evaluating a free, open-source Laravel starting template that removes roughly a day of setup work each time we extract shared logic into a reusable package. It is not a customer feature and adds no runtime dependency or infrastructure cost — our engineers copy the structure into our own repositories and own it from there. The strategic value is consistency: one agreed way to build and consume internal packages, which reduces onboarding time and upgrade surprises. Cost is near zero; the main risk is that the template is early-stage and unmaintained, which we mitigate by copying rather than depending on it.

To engineering (the substance):

• This is a scaffold you vendor, not a library you composer require long-term. Fork or copy, pin the structure, and own it. That bounds supply-chain risk to a one-time read of the code.
• The valuable part is the conventions, not the code: PSR-4 layout, auto-discovered provider, mergeConfigFrom() in register(), publish tags per artefact, and a vendor-prefixed config filename. Adopt those conventions even if you reject the repo.
• The one lesson worth internalising from v1.0.1: prefixed config filenames from day one. An unprefixed config file in a host app is a namespace collision waiting to happen, and renaming it later causes a silent fallback to package defaults that shows up as "credentials look empty" in production, not as an error.
• Whatever we adopt, add a deploy-time assertion that the expected config key exists and is non-default after config:cache. That converts the package's one realistic failure mode — silent config fallback on upgrade, plus stale config caches and Octane/queue workers holding pre-deploy values — from an incident into a failed build.
• Recommendation: pilot in one non-production app, use it as the basis for an internal template rather than an external dependency, and revisit only if we find ourselves creating packages often enough to justify formal enablement.