Core Laravel Package

Product Decisions This Supports

• Build vs. buy for the back-office. Enso bundles the "undifferentiated heavy lifting" of an admin surface — users, roles and permissions, menu builder, activity log, file uploads, CRUD scaffolding. Adopting it is a decision to buy roughly 2–4 engineer-months of scaffolding rather than build it.
• Roadmap sequencing. It front-loads admin capability so product engineering goes to domain features instead of auth/menu/permission plumbing.
• Platform commitment. laravel-enso/core is a dependency aggregator, not a feature library. Choosing it means committing to the whole Enso ecosystem and its Laravel/Vue version constraints — a platform call, not a package call.
• Use-case fit. Strongest for internal ops tools, ERP-lite backends, and CRUD-dominant customer portals; weak for API-first or design-differentiated products.
• Stack and hiring. Implies a Laravel + Vue team willing to learn Enso's conventions and own upgrades.

When to Consider This Package

Consider it when:

• You're building an internal admin/back-office with conventional CRUD, RBAC, menus, and audit trails.
• The team is already Laravel-native and prefers a batteries-included admin to composing Filament/Nova/other panels piecemeal.
• You value convention and speed over bespoke UI.
• You're prepared to vendor/fork and own the upgrade path.

Look elsewhere when:

• You need active maintenance. The last release is 2018-09-27; this aggregator appears dormant. Verify against the upstream laravel-enso/enso repo and its supported Laravel versions before betting on it.
• You need current Laravel (9/10/11) or a modern front-end stack out of the box.
• You need headless/API-only, or a front end designers will heavily customize.
• You want a small dependency surface — a meta-package pulls a large transitive tree you don't control individually.
• You require vendor SLAs, security-patch cadence, or long-term support.

The 35-star count is expected for a meta-package, but it's still a signal: community gravity lives in the parent repo, not here.

How to Pitch It (Stakeholders)

Executives: Enso is not a product feature — it's an accelerator for the admin side of the product. It can compress months of plumbing (auth, permissions, menus, audit logs, CRUD screens) into weeks, which is real time-to-market. The trade-off is maintenance risk: the core aggregator hasn't shipped since 2018, so adopting it means we own the upgrade path. Recommend a time-boxed spike, not a strategic bet, unless upstream activity checks out.

Engineering: Treat it as a dependency aggregator, not a library. Review the full transitive tree, pin versions, and confirm Laravel/PHP compatibility against our target runtime. Assess fork cost and the effort to escape if the ecosystem stalls. Enso imposes conventions across models, routes, and UI — factor in onboarding time. Run a proof-of-concept covering one real CRUD module end-to-end, plus a documented exit plan, before committing.

Combined recommendation: Adopt only for internal, CRUD-heavy surfaces where speed outweighs longevity; otherwise prefer an actively maintained alternative.