- What is laravel-enso/core and what does it actually install?
- It is a Composer metapackage rather than a conventional library: its main artifact is a composer.json that pins a coherent set of roughly 10 to 15 sibling Enso packages, including structure, permission, menu, action-logger, activities, helpers, units and frontend assets. Almost none of the runtime logic lives in this repository itself; it exists so you can pull one mutually compatible version set instead of wiring a dozen packages by hand. In practice, requiring it means adopting the entire Enso back-office platform.
- Which Laravel and PHP versions does laravel-enso/core support?
- The last tagged release is from 2018-09-27, which anchors the pinned dependency set to the Laravel 5.5 to 5.7 and PHP 7.1 to 7.3 era. Those Laravel versions and PHP releases are long past end of life and receive no security fixes. Before committing, run a clean install and verify which versions the current dependency tree actually resolves against, and check whether the sibling packages have moved forward since.
- Is laravel-enso/core still maintained?
- By itself the aggregator is effectively frozen, with no release since September 2018. Metapackages rarely accumulate stars (this repository has around 35), so health should be judged on the whole Enso family: commit cadence, open-issue triage and release recency across the required packages. Also confirm whether the project consolidated into a different top-level package or application template, and evaluate that instead if so.
- Can I install laravel-enso/core in an existing Laravel application?
- It is a poor fit for incremental adoption inside an existing Laravel codebase. Enso is an opinionated scaffold with strong conventions around the User model, permissions, menus, routing and migrations, so it will collide with a host application's own auth and routing setup. Treat it as a platform decision that suits greenfield internal admin or back-office apps wanting the Enso conventions wholesale.
- How is laravel-enso/core different from the other Enso packages?
- laravel-enso/core is the aggregator; the real functionality lives in the sibling packages it requires, such as structure, permission, menu, action-logger, activities, helpers and units. Requiring core is a shortcut for getting a mutually compatible set of those packages without pinning each one yourself. Fixing a bug or adding a feature almost always means working in one of those sibling repositories, not in this one.
- How do I install laravel-enso/core?
- Installation is a single composer require of the aggregator, which pulls the compatible Enso package set, followed by Enso's installer and publish flow to handle configuration and asset publication. You also need a Laravel application matching the pinned version range (the 5.5 to 5.7 era) and a Node toolchain capable of building the Vue 2 frontend. Verify the resolved versions on a clean install before committing, since the pins are dated.
- Does laravel-enso/core require Vue 2 and how do I rebuild the frontend assets?
- The Enso SPA of that vintage typically depends on Vue 2, Webpack and node-sass or Laravel Mix, so rebuilding the assets on a current Node LTS is a known pain point. That is a second upgrade axis entirely separate from the PHP side, and it should be budgeted for explicitly. If rebuilding proves impractical, consider serving pre-built assets until you migrate the frontend.
- What are the alternatives to laravel-enso/core for a Laravel admin panel?
- It depends whether you want an Enso-style scaffold or just an admin panel: common alternatives include Laravel Nova, Filament, Backpack and Orchid, or a bespoke Laravel plus Vue admin build. None of them reuse Enso's permission, menu and structure conventions, so switching means re-implementing that model. If you specifically want Enso, first check whether the project now publishes a newer entry point or starter template.
- How do I patch a transitive dependency pinned by laravel-enso/core?
- A metapackage only helps while its pins resolve; if you need a security patch in a transitive dependency such as the framework or an HTTP client, you may have to fork the aggregator or override constraints in your own composer.json. At that point you own the compatibility matrix yourself. Test any override on a branch with a clean install and a full migration run before relying on it.
- Is laravel-enso/core safe to run in production long term?
- Running it in production means accepting that the pinned Laravel and PHP versions are unsupported and receive no security patches, unless the sibling packages have since been updated and the aggregator superseded. For an admin panel you expect to run for five years or more, confirm the maintainer situation and bus factor, the licence and community model, and whether a supported upgrade path exists. If those checks fail, treat it as a legacy or internal-only tool rather than a new production platform.