Core Laravel Package

Getting Started

Before writing a line of code, confirm what you actually have. salt/core is described as the shared logic/templates/components layer for Salt web applications — meaning it is a library, not an application. It has zero stars, zero dependents, and a sparse release history (a long gap after January 2023, then 1.1.2), so treat it as vendored third-party code you are adopting, not a community package you are consuming.

Minimal path:

composer require salt/core:1.1.2
composer show salt/core          # confirm the resolved version + constraints

Then read, in this order, inside vendor/salt/core:

1. composer.json — required PHP and illuminate/* constraints. This is your compatibility answer for Laravel 10/11 before anything else.
2. src/ service provider(s) — what is registered, what is bound into the container, what is auto-discovered.
3. src/ menu classes — MenuItem in particular (see routeGroup below). This is the most concrete, documented piece of API surface the package has.
4. config/ — anything publishable; this is the real public API surface.
5. resources/views/ — the templates and Blade components the description refers to.
6. LICENSE — see gotchas; NOASSERTION on Packagist means the license could not be machine-detected.

First use case: get one page rendering through the package's own template stack in a scratch Laravel app, and build one small menu via MenuItem with a routeGroup set, so you can see the active-state indicator work. Publish whatever config and views exist, hit a route, and look at the HTML. If you cannot make a single page render in an hour, stop — the cost of adoption is higher than the value of a zero-dependent package.

Implementation Patterns

Treat the package as a view/component substrate plus a small menu model, not a framework. The realistic integration is: your app owns routing, models, and controllers; salt/core supplies layouts, Blade components, shared helpers, and MenuItem objects for navigation.

• Override via publish, never edit vendor/. Publish views and config into your app, then let Laravel's view resolution prefer your copies. Keep a written list of every file you override — with a thinly-maintained package, you will be diffing these on every update.
• Wrap the package behind one seam. Create a single app-level service (e.g. App\Support\SaltBridge or a small facade) that calls into salt/core. When the package is abandoned or you replace it, you have one file to rewrite instead of a hundred Blade templates. MenuItem construction belongs behind this seam too.
• Build navigation as data, not markup. As of 1.1.2, MenuItem accepts a routeGroup attribute used for downstream "is this menu item active?" indicators. Define your menu tree as MenuItem instances in a dedicated provider/composer, set routeGroup per item (e.g. 'admin', 'account'), and let the package drive the active state rather than hand-rolling request()->routeIs() in Blade.
• Register components explicitly in your own service provider rather than relying solely on the package's aliasing. Names like x-salt.button or x-core.card are prone to colliding with your own components; prefix deliberately.
• Compose, don't fork. Use Blade slots and @include to layer app-specific markup over the package's base templates. Forking templates freezes you out of upstream fixes — and there are still a few arriving.
• Config-driven behavior first. If the package exposes options for something (paths, namespaces, feature flags), use those before subclassing. Subclassing internals is the fastest route to breakage on a minor bump.
• Pin exactly. "salt/core": "1.1.2", committed composer.lock, and mirror the source in a private fork or a repositories VCS entry. Still non-negotiable with 0 dependents and an irregular release cadence.
• Test at the boundary. Write feature tests that assert rendered output of the package's key templates and a test asserting your menu marks the right item active for a given route under each routeGroup. Those tests are your upgrade safety net and your documentation of expected behavior.

Gotchas and Tips

• License is NOASSERTION. This is still the single biggest blocker. It is not "probably MIT" — it means the license file is missing, non-standard, or unparseable. Get legal sign-off or a written clarification from the author before shipping commercially. A patch release does not change this; do not assume permissiveness because it is on Packagist.
• routeGroup is additive but check the constructor. 1.1.2 adds an attribute to MenuItem for downstream active-indicator logic. Confirm from the diff whether it landed as a new constructor parameter, a public property, or a fluent setter. If it is a constructor parameter inserted anywhere but last, code constructing MenuItem positionally will silently shift arguments. Instantiate named or use setters.
• Version line is 1.1.x, not 1.2.x. If you previously pinned a hypothetical 1.2.3, correct it — the resolved stable is 1.1.2. Constrain with ^1.1 only if you are watching the changelog; otherwise pin 1.1.2 exactly.
• Release cadence is the risk, not the release. A single patch after a long dormant period is a good sign but not a maintenance guarantee. Assume no Laravel 11 support until verified: check illuminate/support constraints and whether the provider uses anything removed since (older Blade::component signatures, $this->app->bind patterns that still work but are deprecated). Run composer why-not / composer update --dry-run early.
• Zero stars and zero dependents means no Stack Overflow answers. Budget for reading source. Debug by dd()-ing inside vendor/salt/core/src temporarily, then removing it — there is no community to ask. For routeGroup specifically, read the class and the view that consumes it; there is no documentation beyond the changelog line.
• Active-state mismatches are usually route-name mismatches. The routeGroup indicator compares against your route names/groups. If the indicator never lights up, dump the current route name and the MenuItem's stored value before assuming a package bug.
• View cache is the usual suspect. After publishing or overriding templates: php artisan view:clear && php artisan config:clear && composer dump-autoload. A stale compiled Blade file makes it look like overrides "don't work."
• Namespace and component collisions. Anonymous Blade components resolve by filename across all registered paths. If the package ships button.blade.php and you do too, resolution order decides — and it may not be what you expect. Audit with php artisan about / inspect view.paths.
• Auto-discovery surprises. If the package's provider is auto-discovered, disabling it (adding to dont-discover) can silently break helpers that other packages assume exist. Check bootstrap/cache/packages.php.
• Extension points to look for: container bindings you can swap in your own provider, publishable config, view namespace registration, and any interfaces in src/Contracts. If none of these exist, the package offers no supported customization path — that is itself the finding.
• Write a one-page ADR recording why you adopted it, the pinned version (1.1.2), the license status, and the exit plan. With a package this thin on signals, institutional memory is the only thing keeping the next developer from re-litigating the decision.