Core Laravel Package

Product Decisions This Supports

• Build vs. buy for a shared Laravel foundation. If we are consolidating two or more Laravel applications into a portfolio, salt/core remains a useful reference case study for the "shared core package" pattern — one package holding domain logic, Blade/view templates, and UI components consumed by several downstream apps. It informs the shape of an internal platform package, not the decision to depend on one.
• Scoping an internal platform effort. Reading the source gives a rough inventory of what a "core" layer typically carries (auth/account scaffolding, layout templates, reusable view components, base service providers, navigation/menu primitives). That is a defensible input to a sizing estimate for a 1–2 engineer-quarter internal package — with the caveat that we would write it, not fork it.
• Roadmap risk review for inherited applications. If any app in the portfolio already lists this as a dependency, the decision is vendor-risk remediation, not adoption: pin, fork, or replace. This package is the trigger for that ticket.
• Dependency governance / supply-chain hygiene. A concrete example for the "what do we require before a package enters composer.json" policy — stars, dependents, release recency, license clarity, test evidence, and versioning discipline.
• Semantic-versioning trust in the dependency policy. Release 1.1.2 adds a new public attribute (routeGroup on MenuItem) but ships as a patch. That is a minor-level change under SemVer. It is a small but concrete data point for the policy question "can we let this package float on ^1.1?" — the answer here is no; additions land in patch releases, so version constraints are not a safety mechanism with this maintainer.
• What this does not support: any decision to add it as a dependency of a revenue-bearing product. Still zero dependents; the single 1.1.2 release is a one-line change with no accompanying test, CI, license, or documentation evidence. There is still no proof it has run outside its author's applications.

When to Consider This Package

Adopt or evaluate only under narrow conditions:

• You inherited it. An existing Salt-based application already depends on it. Then the work is fork-and-own: confirm the code is small enough to vendor internally, add CI, and take maintenance responsibility explicitly.
• You are studying the pattern. A timeboxed (≤ half a day) architectural read before designing our own shared-core package. Copy concepts, not code.
• You are inside the originating organization or have a direct line to its maintainers, where license ambiguity and staleness are resolvable by conversation.

Look elsewhere — or build — in every other case, specifically when you need:

• License certainty. NOASSERTION remains unchanged as of 1.1.2. Commercial reuse requires legal review before a single line is copied; that alone kills most adoption paths.
• Framework currency. No release note in 1.1.2 references a Laravel major, PHP version bump, or compatibility fix. Assume compatibility work on service providers, Blade compilation, and PHP constraints until proven otherwise.
• Support and security response. One patch release does not establish a patch cadence. The 1.1.2 changelog is a single bullet for a single downstream app's menu-indicator need — reactive, incidental maintenance, not a support commitment. A CVE in a transitive dependency would still land on us.
• Predictable upgrade semantics. Adding a public attribute in a patch release means a composer update on a ^1.1 constraint can change the shape of objects our templates consume. We would need to pin exact versions and read every diff.
• Any adoption signal. Zero stars and zero dependents is not disqualifying for a private internal package, but this one is public. Public + unadopted + one-line releases usually means "extracted for one consumer, never published for a market."
• Documentation, examples, or a test suite you can inspect. 1.1.2 adds a property with no accompanying tests or docs. Integration risk remains unquantified.

The default answer for greenfield work is a maintained starter kit (Jetstream, Filament, an Inertia/Laravel skeleton) plus a thin in-house core we control.

How to Pitch It (Stakeholders)

For executives (one paragraph): We re-reviewed salt/core, an open-source Laravel package that bundles shared logic and templates for a family of web applications, after its 1.1.2 release. The release is one line: a new attribute on a menu-item class, added for the maintainer's own downstream app. It changes nothing about the fundamentals — still no external users, still no clear license, still no tests, docs, or support commitment — so it is still not a candidate for adoption. The one new signal is diagnostic rather than reassuring: a feature was shipped as a patch release, so we could not safely rely on version numbers to gate upgrades. The cost of a dependency is not the install; it is the multi-year tail of upgrades and security patches. Our recommendation is unchanged: spend a short, bounded amount of engineering time reading it as a design reference for a foundation layer we build and control, and formally retire it if it appears anywhere in our existing dependency tree.

For engineering (the ask): Treat it as literature, not a library. Timebox a review to a few hours; extract the package's decomposition — what it puts in templates versus components versus domain services — and discard the implementation. Do not vendor the code until legal clears the NOASSERTION status. If we discover a live dependency in one of our apps, open a remediation ticket immediately, treat the fix as fork-and-own, and pin an exact version rather than a caret range. Note that 1.1.2's MenuItem::routeGroup is an append-only public API change, so it is low-risk to read and a fair cue for what "maintenance" looks like here: one attribute, no tests, no migration note.

What would change this recommendation: a named and responsive maintainer, an OSI-approved license, a release within the last twelve months that explicitly targets the current Laravel major and ships with a visible test suite and CI badge, conformance to SemVer, and at least a handful of independent dependents. 1.1.2 satisfies at most the "a release exists" fragment of one of those five, and does so without evidence of framework currency or test coverage. The answer stays no.