Orm Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. It ships a Bundle subclass and Doctrine ORM glue; there is no service provider, no config/orm-bundle.php, and nothing for Laravel's container to auto-discover. If you arrived here from a Laravel codebase, stop and check whether you actually need it — the helpers are Doctrine-specific and will not work against Eloquent. In a Laravel app you would have to port the classes by hand, at which point you are just writing the helpers yourself.

For a Symfony app, the honest starting position is that this package has 0 stars, 0 dependents, and no documentation. Treat src/ as the documentation.

1. Read the source before installing. Clone or browse the repo and list the tree:

   git clone https://github.com/silpo-tech/ORMBundle && cd ORMBundle
   find src -type f -name '*.php' | sort
   cat composer.json
   

   You are looking for three things: the *Bundle.php class (its exact namespace), whether DependencyInjection/Configuration.php exists (i.e. whether there is anything to configure), and what composer.json requires — specifically the doctrine/orm and doctrine/dbal version constraints.

2. Install, pinning the version. Given the health signals, do not use an unconstrained require:

   composer require silpo-tech/orm-bundle:^1.0   # match the actual release line you saw
   

   Commit composer.lock. This is one of the few packages where you want the lock file to be the source of truth about what you reviewed.

3. Register the bundle in config/bundles.php using the class name you confirmed in step 1:

   return [
       // ...
       SilpoTech\ORMBundle\SilpoTechORMBundle::class => ['all' => true],
   ];
   

4. Check for a Flex recipe. There almost certainly isn't one. If bin/console config:dump-reference <alias> returns "no extension", the bundle has no Configuration class and needs no config/packages/*.yaml file at all. Don't invent one.

5. Confirm Doctrine is already working. The bundle is a helper layer; if doctrine:schema:validate and doctrine:mapping:info are not clean before you add it, you will not be able to tell whether a failure is yours or the bundle's.

First use case: pick exactly one helper — typically an entity trait (timestamps, UUID/blame) or an abstract base repository — apply it to a single sandbox entity, then run bin/console doctrine:schema:validate and bin/console doctrine:migrations:diff. If the diff is what you expected, expand. If it is empty when you expected columns, the trait is inert (see Gotchas).

Implementation Patterns

Compose via traits, not inheritance. Helper bundles of this shape almost always expose entity traits. Use them with use inside your entities and keep your own base classes free of them, so removing the package later is a mechanical edit rather than an inheritance rewrite:

#[ORM\Entity(repositoryClass: OrderRepository::class)]
#[ORM\HasLifecycleCallbacks]          // required if any trait uses PrePersist/PreUpdate
class Order
{
    use TimestampableTrait;           // name per src/ — verify
    use UuidIdentifierTrait;
}

Wrap repositories behind your own methods. If the bundle provides an abstract repository or query-builder helpers, extend it but expose only your domain methods. Call sites should never reference the bundle's namespace directly:

// app-side repository — the only place that knows about the bundle
final class OrderRepository extends BaseRepository  // bundle class
{
    public function findOpenForCustomer(CustomerId $id): array
    {
        return $this->createOpenQuery($id)->getResult();   // thin passthrough
    }
}

This is the single highest-value habit with a low-traffic dependency: one seam, one file to change when the package is abandoned.

Register repositories in mapping, not in services. Doctrine's repositoryClass: attribute is the supported entry point. Manually tagging repositories as services tends to produce two instances with different state.

Discover service ids rather than guessing. Before decorating or overriding anything, enumerate what the bundle actually registers:

bin/console debug:container --show-private | grep -i orm
bin/console debug:config <bundle_alias>        # only if a Configuration class exists

Prefer decoration over forking. If a helper does 90% of what you want, decorate the service (decorates: some_service_id in services.yaml) or subscribe to the Doctrine events you need. Copying classes into src/ forfeits upstream fixes and, given the release cadence, you may be the only consumer anyway — but decoration keeps the diff reviewable.

Always diff the schema after adoption. Any trait that adds persisted state must produce a migration in the same PR:

bin/console doctrine:migrations:diff
# read the generated file before committing — traits add columns silently

Add a mapping assertion to CI. bin/console doctrine:schema:validate --skip-sync catches broken mappings and invalid attribute usage on every build, which matters more than usual here because you have no upstream test suite to lean on.

Gotchas and Tips

• Lifecycle callbacks are the classic silent failure. If a trait declares #[ORM\PrePersist] and the entity lacks #[ORM\HasLifecycleCallbacks], the method never runs, no error is raised, and your created_at is null in production. Grep every trait you adopt for PrePersist|PreUpdate|PostLoad and add the class-level attribute.

• Version compatibility is the main install risk. Read composer.json's require block before you composer require. Helper bundles often lag: Doctrine ORM 3.x removed annotation support and changed several APIs, and DBAL 4.x tightened type handling. If the constraint caps at doctrine/orm ^2.x and you are on 3, Composer will either refuse or you will get runtime breakage in onFlush listeners.

• No recipe means no config, and no config means no toggles. If there is no DependencyInjection/Configuration.php, there is no way to disable a stubbornly-registered listener via YAML. Your only levers are service decoration, compiler-pass manipulation, or removing the bundle registration. Confirm this early — it changes your integration plan.

• Watch for unconditionally registered event subscribers. Run bin/console debug:event-dispatcher before and after enabling the bundle and note the delta. Subscribers on onFlush/postFlush can quietly alter your unit-of-work behaviour, and that shows up as "impossible" bugs in unrelated code.

• Pin and audit. 0 stars, 0 dependents, and a single maintainer org means the bus factor is effectively one team at Silpo. Pin the version constraint, commit the lock, and if your organisation runs composer audit or a dependency-review gate in CI, this package will likely need an explicit allow-list entry with a written justification.

• Keep an exit ramp documented. These bundles are usually a few dozen small classes. Note in your README which helpers you actually use. If you use three traits, inlining them later is an afternoon; if you used "everything," it is a project. The 16/100 health score is the reason to plan for that now rather than after the package is archived.

• License is MIT, so vendoring or forking into your own namespace is legally fine — retain the copyright notice and the license text if you do.

• The release date metadata is not a maturity signal. A recent tag on a 0-star repo usually means the org extracts a monorepo package on a schedule, not that the library is battle-tested by a community. Judge it by the code you read in step 1, not the tag.