Core Laravel Package

Getting Started

laravel-enso/core is best understood as a Composer dependency aggregator, not an application API you call directly. Its job is to pull in and constrain the Enso packages that provide the admin foundation: users, roles, permissions, menus, configuration, helpers, and related core services.

Start here:

1. Check compatibility before installing. The last release is from 2018, so verify the package’s composer.json constraints against your PHP and Laravel version. On a modern Laravel app, expect conflicts unless you are maintaining a legacy Enso installation or are prepared to fork/upgrade dependencies.
2. Read vendor/laravel-enso/core/composer.json. This is the most important file. It tells you which Enso packages are actually installed and which versions are pinned.
3. Inspect the service provider. Look for src/ServiceProvider.php or the provider declared in composer.json. This shows what gets registered, published, and bootstrapped.
4. Publish and migrate. Use the provider/tag documented by the installed version, then run the Enso migrations and seeders. A typical flow is:

   composer require laravel-enso/core
   php artisan vendor:publish --provider="LaravelEnso\Core\ServiceProvider"
   php artisan migrate
   

   Use the actual provider class and publish tags from the installed package if they differ.
5. Seed permissions and menus. Enso’s admin UI depends on seeded roles, permissions, and menu entries. Find the package seeders under database/seeders or the dependency packages’ Database/Seeders directories and run them in the documented order.
6. Log in and inspect the admin shell. The first practical use case is bringing up an Enso-style admin area for users, roles, permissions, and navigation, then layering your domain modules on top.

If you are starting a brand-new project today, prefer the maintained Laravel Enso skeleton or a current fork rather than assembling laravel-enso/core manually. If you are maintaining an existing Enso app, this package is the version anchor for the whole admin stack.

Implementation Patterns

Treat laravel-enso/core as the integration contract for the rest of the Enso modules.

• Pin the whole Enso stack together. Do not upgrade one Enso package independently. Use the constraints from core’s composer.json and keep laravel-enso/* versions aligned. In practice, commit composer.lock and avoid broad * constraints.

• Put application code in local modules, not in vendor packages. Follow Enso’s module shape for your own features: service provider, routes, migrations, permissions, menu entries, policies, and controllers. This keeps admin features discoverable and upgradeable.

• Use Enso’s permission and menu model as the source of truth.

  A typical workflow is:

  1. Create a permission for the new resource/action.
  2. Attach it to roles.
  3. Add or seed a menu entry pointing at the route.
  4. Protect routes with the appropriate Enso middleware/permission checks.
  5. Clear caches after seeding so the menu and permissions appear.

• Seed idempotently. Menu and permission seeders should use firstOrCreate/updateOrCreate patterns so repeated deployments do not duplicate entries. Keep seeders in version control alongside migrations.

• Extend through configuration and providers. For app-specific behavior, prefer config overrides, published config files, service providers, and Enso extension points. Avoid editing files inside vendor/.

• Reuse the auth/admin shell. Let Enso handle login, users, roles, permissions, and navigation. Build domain CRUD around those primitives rather than creating a parallel admin auth system.

• Integrate domain packages as Enso-aware modules. If your app has invoices, projects, or tickets, expose them through Enso routes/controllers/tables and register their permissions/menus. This is where day-to-day leverage comes from: consistent admin conventions instead of one-off screens.

• Deployment pattern. On each deploy: install locked dependencies, run migrations, run idempotent seeders if needed, rebuild frontend assets if the Enso version requires it, then clear config/route/view caches.

• Upgrade pattern. Upgrade in a branch, run composer update laravel-enso/* --with-dependencies, inspect migrations and publishable assets, run the test suite, and manually smoke-test login, menus, permissions, and one CRUD flow.

Gotchas and Tips

• It is an aggregator, so debugging often leads elsewhere. If a feature is broken, the code is probably in a dependency such as permissions, menu, users, or helpers. Start with composer show and vendor/laravel-enso/*.
• The 2018 release date is the biggest risk. Expect old Laravel/PHP constraints, outdated transitive dependencies, and composer conflicts on modern projects. Audit with composer outdated and a security scanner before using it in production.
• Watch migration and seeder order. Enso packages often ship migrations and seeders that depend on each other. Publish/run them in the documented order; back up the database before first migration on an existing app.
• Cache invalidation is a common failure point. After changing menus, permissions, config, or routes, run:

  php artisan config:clear
  php artisan route:clear
  php artisan view:clear
  php artisan cache:clear
  

  In production, follow with the appropriate cache:* commands if you cache config/routes.
• Do not hand-edit vendor files. Override config, publish assets, or create a local module. Vendor edits disappear on the next composer install.
• Menu and permission drift causes “invisible” features. A route may work while the menu item is missing, or the menu may show while the permission denies access. Check both the seeded menu table and the role-permission assignments.
• Route and middleware collisions are easy. Enso usually owns an admin prefix and auth middleware. Check existing route names and prefixes before adding your own admin routes.
• Frontend assets matter. Older Enso versions may depend on specific build tooling or published assets. If the UI looks unstyled or menus do not work, verify that assets were published/built and that the layout is using the expected stack.
• Use extension points instead of fighting the framework. Prefer Enso’s service providers, config, events/listeners, policies, and published views/components. If you need different behavior, wrap or override at the application layer.
• Keep a smoke-test checklist for upgrades: login, user CRUD, role assignment, permission checks, menu rendering, one domain CRUD screen, and queued jobs/notifications if used.
• For new work, evaluate alternatives first. For legacy Enso maintenance, laravel-enso/core is the correct anchor. For a new admin panel, a maintained Enso fork or a modern Laravel admin stack will usually be less risky.