- What is salt/core used for?
- Salt Core is the shared kernel of Salt web applications. It houses the core logic, templates and components used by Salt-based projects, most likely base service providers, Blade view components, config stubs and possibly migrations that a Salt application skeleton depends on. Its stated goal is to standardize integration and reduce duplicated code across related Salt packages. It is not a general-purpose library with an external consumer base, so it is only relevant if you are building on the Salt platform.
- Is salt/core a general-purpose Laravel package I can drop into any project?
- No. A package whose value proposition is the internals its own applications share typically assumes conventions, directory layouts and sibling salt/* packages that may not be published. Adopting it standalone risks dragging in an unpublished dependency graph or forcing you to reconstruct the parent skeleton. It fits only if the decision to build on the Salt platform has already been made.
- How do I install salt/core with Composer?
- Installation itself is presumably a simple composer require salt/core, but the hard part is organizational rather than mechanical. Before installing, inspect the composer.json require and repositories blocks to confirm whether unpublished sibling packages are needed. Also check whether salt/core is still the current artifact or has been superseded by a renamed or private package in the same GitHub organization.
- Which PHP and Laravel versions does salt/core support?
- Compatibility is unverified. The last release was January 2023, which puts it roughly two Laravel major versions behind, since Laravel 10, 11 and 12 have shipped since then. Whether it works cleanly on PHP 8.3 or 8.4 and current illuminate/* constraints is an open question, and on base rates for a dormant package it is unlikely to be clean. Read the declared constraints in composer.json and look for CI proving them before relying on any claim.
- Is salt/core still maintained?
- No meaningful maintenance signal exists. The last release was January 2023, so abandonment risk is effectively realized rather than prospective, and there is no maintenance commitment to lose. Zero stars and zero dependents also means no external party has ever exercised this code publicly, no issue tracker corpus exists, and nobody outside the vendor is likely to notice or care if it breaks.
- What license does salt/core use, and can I use it commercially?
- Packagist reports NOASSERTION, meaning the license could not be mapped to a recognized SPDX identifier, which usually points to a custom license, a missing license file, or a non-standard notice. Until legal has read the actual LICENSE file, commercial use is an open question. With zero public adopters there is no community precedent to lean on, so do not assume permissive terms.
- Does salt/core work with Laravel 11 or Laravel 12?
- That is unverified. The package predates both releases, and dormant core packages often pin dormant dependencies that can anchor your composer.lock and block framework upgrades across your estate. Test it on a throwaway branch with your target Laravel and PHP versions before committing to it. If the constraints conflict with your application, expect to fork or patch rather than wait for an upstream fix.
- How should I test salt/core before using it in production?
- Treat it as a platform dependency rather than a normal Composer package: install it in an isolated application, boot the service providers, publish config, and confirm no migrations or views collide with your own. Run your full test suite plus an upgrade rehearsal against your target Laravel version, since core-layer failures tend to surface during framework upgrades rather than at install time. Also review what it auto-registers, because container bootstrapping and view rendering hooks are hard to observe once deployed.
- What could break in production if I add salt/core?
- The risk is concentrated in three areas. Transitive exposure is the first: a dormant core package often pins stale dependencies that constrain your whole dependency tree. The second is deep coupling with low observability, since core packages touch service container bootstrapping, view rendering and sometimes migrations, so failures appear late, during upgrades or in production rendering paths. The third is collision risk from auto-registered providers, publishable config and shipped migrations overlapping your application's own.
- Are there alternatives to salt/core for a Laravel application?
- For a vendor-neutral codebase, the practical alternative is not adopting it at all: use Laravel's own illuminate/* components and first-party packages, or extract only the few utilities you actually need. There is no meaningful community fork or third-party replacement to evaluate, because the package serves a single vendor's application family. If you are or will be a Salt customer, salt/core is not really a choice but part of the platform contract, and the work shifts from should we adopt to how do we contain it.