Getting Started

Install the package with Composer and publish any package config/service provider hooks using the package README. Start with config/modular-api.php if present, then inspect the package service provider to understand how modules and API routes are discovered.
First place to look: the package README, config file, module directory conventions, and any tests/fixtures covering “Api type” detection. v1.0.3 fixes API type identification extraction, so verify how your module folders/files are classified before building on auto-discovery.
First use case: create one small module, e.g. Billing, add a versioned API route and controller inside it, register/load the module, then confirm the endpoint appears in php artisan route:list and responds through your normal API middleware stack.
Upgrade to v1.0.3 if you rely on automatic API module/type detection; it is a patch release with no documented breaking changes.

Implementation Patterns

Organize by bounded context: keep each module’s routes, controllers, form requests, API resources, policies, events, and service classes together. Let the package handle module registration/discovery rather than manually requiring route files.
Use module-level route groups for API versioning, prefixes, and middleware. Apply auth/sanctum, throttling, and API middleware at the module boundary so every endpoint inherits consistent behavior.
Keep cross-module coupling low. Share contracts, DTOs, or actions only where necessary; avoid direct model access across modules.
Integrate with standard Laravel conventions inside modules: form requests for validation, API resources for responses, policies/gates for authorization, events/listeners for side effects, and queued jobs for slow work.
Write feature tests per module, plus a smoke test that asserts expected module routes exist. This catches discovery/type-identification regressions quickly.
For larger APIs, treat modules as deployable slices: one module per domain area, explicit service provider bindings, and package-level config for discovery paths/prefixes rather than hard-coded paths.

v1.0.3 fixes API type identification extraction. If modules were previously skipped or misclassified, upgrade and re-check discovery. If detection still fails, inspect folder naming, config markers, and package expectations before adding workarounds.
Clear caches after adding/moving modules: php artisan optimize:clear, plus route/config cache rebuilds. Cached routes are a common reason new module endpoints do not appear.
Run composer dump-autoload after adding module namespaces/classes. Discovery may find a module before Composer can autoload its classes.
Use php artisan route:list as the first debugging step for missing endpoints. Then inspect package service provider boot order and module registration logs/tests.
Check config quirks early: published config path, module discovery directories, API prefix/version settings, and middleware groups. Keep local overrides in app config, not vendor files.
Prefer explicit tests over relying only on auto-detection for critical modules. A simple route-existence test is cheap insurance against extraction/discovery changes.
Extend through package config, custom service providers, or documented extension points. Avoid editing vendor code; keep custom module resolvers/type detection overrides in application code.
Patch upgrade risk is low, but run your module route/discovery tests after upgrading to v1.0.3.