Weave Code
Odm Bundle Laravel Package
silpo-tech/odm-bundle
Symfony bundle that integrates Doctrine ODM (MongoDB) document mapping into your app, with ready-made services, configuration and DI wiring so you can set up document-based persistence quickly and consistently.
A Symfony bundle that contains common used ODM classes (e.g. Validators)
Frequently asked questions about Odm Bundle
- Is silpo-tech/odm-bundle a Laravel package?
- No. It is a Symfony bundle: the -bundle suffix, the Bundle subclass, the Extension::load() registration, and a possible compiler pass all point to a package of type symfony-bundle. Laravel has no bundle registry, no registerBundles() kernel hook, and no execution point for Extension::load() or compiler passes. The Laravel analog would be a service provider plus a publishable config file, which is similar in intent but mechanically different. Consuming it as-is is not possible; you would be re-implementing its registration layer.
- Will composer require silpo-tech/odm-bundle work in a Laravel app?
- It will almost certainly install cleanly, because laravel/framework already pulls symfony/http-kernel transitively, so the Bundle base class autoloads. That is the trap: the package appears in composer.json and does nothing. There is no error and no warning because the bundle simply never boots. Any value has to be extracted manually from the source.
- Which ODM does this bundle actually wrap?
- The overview describes common ODM classes such as validators, while the blurb says Doctrine ODM for MongoDB. You should confirm in composer.json whether it requires doctrine/mongodb-odm, or whether ODM here means an Elasticsearch document mapper or a Silpo-internal abstraction. This ambiguity matters because it determines whether the ported code targets a real, documented persistence library. Resolve it before committing to any migration effort.
- How do I install and configure it in Laravel?
- You cannot consume it the way it was designed. The recommended path is to fork or copy the bundle source, read the Extension::load() tree, and translate it into a ServiceProvider with a published config file and explicit bindings. That takes roughly 2 to 4 days for a developer comfortable with Symfony DI, and 1 to 2 weeks for a Laravel-only developer. A Symfony kernel bridge or a sidecar Symfony service are the alternatives, but both add permanent complexity.
- Which Laravel versions does it support?
- None explicitly, because it has no Laravel constraints at all. It targets PHP 8.x and specific Symfony component versions, so compatibility is with Symfony component ranges rather than Laravel minor releases. Check the composer.json constraints against the Symfony versions your Laravel version already resolves to. Conflicts are possible if the bundle requires a newer Symfony component than your Laravel release pins.
- Does it hard-require symfony/framework-bundle?
- This is a key question to answer from composer.json before adoption. If symfony/framework-bundle is a hard requirement, installing this into a Laravel app drags in the full FrameworkBundle, which is heavy and risks container and version conflicts. If it only requires individual Symfony components you already have transitively, the install is far less disruptive. The difference changes whether composer require is harmless or destabilizing.
- Is silpo-tech/odm-bundle safe to depend on in production?
- Treat it as high risk as a dependency and high value as reference material. It has zero stars, zero dependents, and no issue corpus, Stack Overflow answers, or third-party validation, and there is no ecosystem pressure to keep its public API stable. It appears to be an internal Silpo artifact published to Packagist for their own microservices, so the public surface is a side effect. The MIT license and likely small codebase make a source audit cheap, measured in hours rather than weeks.
- How should I test a Laravel port of this bundle?
- Since the original bundle never boots in Laravel, your tests should cover the ported ServiceProvider rather than the package. Unit test the container bindings and config merge, then integration test against a real MongoDB instance or a containerized one to confirm document mapping and validators resolve correctly. Assert that configuration values flow from your published config file into the bound services. Do not assume the bundle's own tests provide Laravel-compatible coverage.
- What are the alternatives for MongoDB document mapping in Laravel?
- If you need ODM-style mapping, consider laravel-mongodb for Eloquent-style MongoDB access, or Doctrine MongoDB ODM wired through your own service provider. If the real value here is specific Silpo classes such as validators, porting just those classes may be far cheaper than adopting the whole bundle. Evaluate whether a Symfony sidecar service fits better if the mapping logic is entangled with Silpo infrastructure.
- Who maintains silpo-tech/odm-bundle and is there a semver policy?
- It is maintained by silpo-tech, the Silpo engineering team, for their own internal microservices. A release around October 2025 suggests active internal maintenance, but that cadence serves their needs rather than yours. There is no visible commitment to semver, no public deprecation policy, and no community support channel. Forking puts the API and upgrade cadence under your control.
Weaver
How can I help you explore Laravel packages today?