Concord Laravel Package

Getting Started

Start by installing the package via Composer and registering it in config/concord.php. The core workflow involves:

1. Create an in-app module: php artisan make:module Orders
2. Implement module functionality (models, controllers, views) inside app/Modules/Orders/
3. Activate the module by adding its ModuleServiceProvider to config/concord.php
4. For reusable modules (e.g., from vendor/), ensure they follow Concord conventions (e.g., ModuleServiceProvider, config/, database/migrations/) First use case: scaffold a small business module (e.g., Products) for reuse across multiple internal apps—concentrate on decoupling the logic, avoiding direct dependencies on app-specific code.

Implementation Patterns

• Standardize module structure: Place models, controllers, views, migrations, and config under app/Modules/{Name}/ or src/ for external modules.
• Use BaseBoxServiceProvider: Extend it instead of ServiceProvider to gain Concord’s conventions (e.g., auto-discovery of config, views, lang, migrations).
• Customize behavior: In external modules, override config via config/mybox.php, publish views, or extend models (e.g., App\Models\Product extends \Vendor\MyBox\Models\Product).
• Route isolation: Register routes in Routes/web.php and Routes/api.php inside the module; Concord auto-loads them.
• Leverage events: Define default event-listener bindings in the module’s EventServiceProvider, then override them in the host app using event bindings configuration.
• Scaffold helpers: Use classpath_to_slug() and morph_type_of() for consistent naming in logs, policy keys, and polymorphic relations.

Gotchas and Tips

• No auto-discovery yet (v1.x): Unlike native Laravel packages, modules must be explicitly listed in config/concord.php—watch for typos in provider class names.
• Config precedence: External module configs (e.g., vendor/vendor/module/config/mybox.php) must be published/config-merged manually; use config('mybox') only after publishing or with explicit merging.
• Model overrides: To customize behavior, prefer aggregation (e.g., traits, decorators) over inheritance; avoid binding traits in modules that apps are expected to extend.
• View namespaces: Concord supports view namespaces, but conflicts arise if multiple modules register conflicting paths—use unique prefixes (e.g., module::orders.index).
• Migration collisions: Run migrations in order using timestamps (e.g., 2024_05_01_000000_create_orders_table.php) and avoid hard-coded IDs in foreign keys.
• Upgrade path awareness: v2.0 will drop the centralized concord.php and use auto-discovery—plan modular code to be forward-compatible (e.g., avoid concord:* commands in scripts).
• Testing tip: Mock ModuleFactory or use App::bind() in tests to override module bindings without modifying config/concord.php.