Getting Started

monofony/core-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/monofony.php publish tag, and no Eloquent integration. That single fact should shape how you "get started": if your day job is Laravel, you are not going to composer require this beside laravel/framework and have a productive afternoon. You either treat it as (a) a reference architecture you read for domain-modeling ideas, or (b) a dependency in a separate Symfony app (sidecar) that you integrate over HTTP/queue.

Assuming a Symfony app is in scope, the minimal path to a first working page:

Pin before you install. Don't trust ^ ranges — the project is low-activity (2 stars, 0 dependents) and transitive constraints (sylius/resource-bundle, sylius/grid-bundle, sylius/fixtures-bundle, Doctrine extensions) bite hard against your Symfony minor:
```
composer show monofony/core-bundle --all
```
Register the bundle and its companions in config/bundles.php: DoctrineBundle, TwigBundle, SecurityBundle, SyliusResourceBundle, SyliusGridBundle, SyliusFixturesBundle, StofDoctrineExtensionsBundle, then Monofony\Bundle\CoreBundle\MonofonyCoreBundle. Order matters — Monofony assumes Sylius is already wired.

Configure resources in config/packages/monofony_core.yaml:

monofony_core:
    driver: doctrine/orm
    resources:
        app_user:
            classes:
                model: App\Entity\User\AppUser
                interface: Monofony\Contracts\Core\Model\User\AppUserInterface
        admin_user:
            classes:
                model: App\Entity\User\AdminUser
        customer:
            classes:
                model: App\Entity\Customer\Customer

Read the canonical resource keys from vendor/monofony/core-bundle/Resources/config/app/config.yml — that file, not a blog post, is the source of truth for resource names, interfaces, and default service ids.

Create app entities extending the bundle models, add @ORM\Table, implement the matching Monofony\Contracts\... interfaces. Repositories and factories then arrive for free from the resource config.
Resolve interfaces to your classes in config/packages/doctrine.yaml under orm.resolve_target_entities, or any relation typed against a Monofony\Contracts\... interface will fail at runtime.
Write your own migrations — the bundle ships no schema for your app. bin/console doctrine:migrations:diff is yours to run.

First use case: seed an admin user with fixtures and log in through your security firewall. That loop exercises resource config, model extension, Doctrine mapping, and the user provider at once — misconfiguration surfaces immediately, which is exactly what you want from a first spike.

Where to look first: vendor/monofony/core-bundle/Resources/config/ (routing, services, default app config), then the base models under src/ for the properties and interfaces you must satisfy. Skim Monofony\Contracts\ — that's where the domain vocabulary lives.

Implementation Patterns

Extend, never edit vendor. Every model is designed to be subclassed as App\Entity\.... Keep the bundle class as parent, override only table name, indexes, and extra columns. Preserve the interface contract — Symfony will type-hint against it everywhere.

Override by service id, not by copy-paste. Factories, repositories, and form types are registered under predictable ids. Alias or decorate rather than duplicating:

services:
    monofony.factory.customer:
        class: App\Factory\CustomerFactory
        parent: monofony.factory.customer

Confirm the exact parent id in the bundle's service YAML before assuming — these ids are not part of any stable API guarantee.

Resource config as the single wiring point. Once monofony_core.resources.<name>.classes.model points at your class, the controller, repository, factory, and form are all driven from that one declaration. Resist the urge to hand-wire services in parallel — you'll fight the resource resolver.

Custom business logic goes in your entities and factories, not in overrides of core services. If you need a different pricing rule, discount calculation, or workflow transition, model it as a new service or a Symfony Workflow definition wired to the bundle's state machine, rather than patching a vendor service.

Fixtures as the integration test. Because the bundle ships no schema and no seeded data, a fixtures-driven boot (admin user, sample catalog, sample customer) is your fastest regression check after every model change. Keep it in src/DataFixtures and treat it as executable documentation of the wiring.

If you are integrating from Laravel, do not bridge Doctrine entities to Eloquent. Isolate the Symfony app behind a versioned HTTP contract from day one so the boundary can be replaced without touching the Laravel core. The realistic long-term outcome for most teams is porting the concepts into Laravel-native models and dropping the dependency — plan for that exit rather than pretending it won't happen.

Sequencing a spike: 1–2 days to confirm the Symfony-only reality and install cleanly, then a bounded POC (admin login + one resource CRUD) in an isolated container. Do not sequence this behind a product deadline.

Gotchas and Tips

Dependency resolution will likely be your first failure. Sylius + Doctrine + Symfony version pins are old and interdependent. If composer require fights you, you're not doing it wrong — the package's Symfony minor range is probably older than your project.
No Eloquent, no Artisan, no facade. Anything in a Laravel-flavored tutorial (migrations, model factories, php artisan make:) does not apply. Doctrine migrations, Doctrine fixtures, Symfony console.
resolve_target_entities is the #1 runtime footgun. Forget one entry and you get a cryptic "cannot resolve target entity" deep in a relation. When something breaks after adding a new entity, check this file first.
Resource keys are not documented externally. Always cross-check Resources/config/app/config.yml in vendor — the bundle's own default config is the only reliable reference for what a resource is called and which interface it expects.
Interface contracts are wide. AppUserInterface, AdminUserInterface, and CustomerInterface pull in a lot of required methods. Use the bundle's abstract models rather than implementing the interfaces from scratch, or you'll spend a day on boilerplate.
Doctrine extensions (StofDoctrineExtensionsBundle) are load-bearing. Timestampable, sluggable, and similar behaviors may be assumed by base models. Missing bundle config produces null timestamps, not exceptions — subtle and painful.
Debugging DI: bin/console debug:container --tag=monofony... and bin/console debug:container <service-id> are your friends. If a service isn't wiring, it's a compiler-pass or priority problem nine times out of ten, not a missing class.
Extension points are YAML config, not a plugin API. There is no documented extension registry; "extension" here means "subclass + override the resource config + decorate services." That's fine, but it means every customization is a fork-flavored decision — keep them in App\ and diffable.
Maintenance reality: 2 stars, 0 dependents, no vendor SLA. Budget for the possibility that you become the maintainer of a fork. Track upstream commits for 30–60 days before committing to production, and keep an exit plan (fork-and-own, or extract-only-the-patterns) written down.
Security patching is your responsibility. MIT means no vendor obligation to disclose or fix. If this ends up in production, put it on the internal CVE-watch rotation.
Ramp-up cost is asymmetric. If your team is Laravel-native, expect 2–4 weeks before one engineer is productive in Symfony DI + Doctrine + Sylius resource conventions — versus days for a native Laravel commerce package. Price that into the spike decision, not after.

Core Bundle Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips