Getting Started

Install tomatophp/tomato-emenu via Composer and pin the exact v0.0.1 version while evaluating it.
Look first at the package README, composer.json, src/, config/, database/migrations, routes, and any published admin/UI assets. The v0.0.1 release notes only link to the changelog, so confirm actual behavior from source rather than assuming features from the package name.
Publish config/migrations/assets as documented, run migrations in a disposable environment, and verify service-provider auto-discovery.
First use case: create a small throwaway menu dataset through the package’s admin/API/views, then render or query it from a Laravel route. This verifies models, relationships, publishing, and integration before using it in a real application.

Implementation Patterns

Keep published config, migrations, and views under version control so package upgrades are reviewable.
Wrap package models/actions behind application-level services or repositories if menu behavior is core to your domain; this reduces coupling to a pre-1.0 API.
Seed starter categories/items with your own seeders rather than relying on package demo data.
Integrate through Laravel conventions where available: service container bindings, events, route middleware, policies, and config overrides.
For day-to-day usage, create/edit menu data in the admin surface, expose read-only menu endpoints or Blade/Inertia views, and cache rendered menus. Invalidate that cache on package model events.
Add feature tests around menu creation, rendering, authorization, and migration rollback before upgrading.

v0.0.1 is an initial pre-1.0 release: expect unstable APIs, incomplete docs, and possible schema/API changes. Pin the version and read the changelog before every update.
Do not infer features from “emenu” alone; inspect providers, config keys, migrations, routes, commands, and publish tags after install.
Watch for common Laravel package issues: provider registration, publish tags, migration ordering, asset publishing, route collisions, and stale caches. Clear config/route/view caches when debugging.
If the package registers admin panel resources, confirm panel-provider registration, authorization policies, and middleware.
Check extension points before customizing: config file, swappable models/table names, published views/components, route middleware, events, and package commands. Avoid editing vendor files.