isolate/doctrine-bridge
A lightweight integration bridge that connects the Isolate package with Doctrine DBAL and ORM, wiring Doctrine connections, entity mapping, and configuration into Isolate's Laravel setup so both libraries work together with minimal configuration and no custom glue code.
Before installing, understand what you are adopting: the last tagged release was September 2015, the repository has essentially no community, and no package depends on it. It is a convenience bridge, not a maintained library, so treat it as reference source you may fork rather than a dependency you can lean on.
A minimal path looks like:
src/. With a bridge this small there are typically only a handful of service providers / bootstrappers that register Doctrine's EntityManager, Connection, and console commands into the Isolate container. That registration logic is the package.composer.json for the Doctrine versions (doctrine/orm, doctrine/dbal) and PHP constraint it was built against. In 2015 that means PHP 5.4–5.6 era and Doctrine 2.4/2.5. Running it on PHP 8+ or Doctrine 3 will almost certainly fail at the type-hint and EntityManager::create() level.composer require isolate/doctrine-bridge
composer require --ignore-platform-reqs against a pinned Doctrine 2.x in a Docker container with PHP 7.4 is the realistic playground.paths.to.entities and database config through Isolate's configuration mechanism, boot the provider, and verify you can $container->make(EntityManager::class) (or the equivalent accessor) and run a trivial $em->getRepository(Foo::class)->findAll(). If that works end-to-end, you know the bridge is mapping its services correctly.If step 3 or 4 fails, stop. Do not spend hours patching a 2015 bridge for a framework with a single GitHub star — wiring EntityManager into a DI container yourself is ~40 lines of code and you keep control.
Assuming you are using it (or a fork of it) as the doctrine wiring layer for an Isolate application:
Service-provider registration. The bridge's job is almost certainly to bind a Doctrine\ORM\EntityManagerInterface singleton and a DBAL Connection into the container. Register the provider once during boot; resolve the entity manager from the container everywhere else. Never instantiate EntityManager::create() in your own controllers — that is exactly what this package is meant to centralize.
Configuration object over inline arrays. Doctrine's Setup::createAnnotationMetadataConfiguration() / createAttributeMetadataConfiguration() takes a metadata paths array, dev-mode flag, and cache. Feed these from Isolate's config so each environment (local, staging, prod) differs only in config, not in code. Keep the bridge dumb: it should read config keys like doctrine.metadata_paths, doctrine.connection, doctrine.proxies, and hand them to Doctrine.
Repository pattern over active-record drift. With a bridge this thin, there is no magic. Define repositories as services and inject the EntityManager into them. This keeps your domain code independent of Isolate-specific container helpers and makes the eventual replacement of the bridge a no-op.
Console commands. If the package ships CLI integration, wire entities generation, schema tool, and migrations through Isolate's console. Otherwise, use doctrine/migrations directly with a standalone bootstrap script — this is often easier than retrofitting a decade-old console bridge.
Migrations as the integration point that outlives the bridge. Whatever happens to the bridge, your migrations/ directory and doctrine/migrations.php config should be framework-agnostic. When (not if) you drop the bridge, migrations keep working.
Forks as a pattern. Because the package is unmaintained, the realistic "implementation pattern" is: fork it into app/Support/Doctrine/ or a monorepo package, delete the Isolate-specific bits you don't use, and own it. That immediately makes the code auditable, testable, and upgradable to Doctrine 3 / PHP 8 attribute metadata.
Test seams. Inject EntityManagerInterface (not the concrete class) into services so tests can swap in a SQLite in-memory entity manager or a mock. A bridge that leaks the concrete container binding into your code is a bridge you cannot test.
This is effectively abandoned. No release since 2015, one star, zero dependents. Do not assume issues will be answered. Budget for full ownership of the code the moment you depend on it. If the goal is simply "use Doctrine with a DI container," consider writing the 30–60 line integration yourself — you will spend less time than debugging 2015-era assumptions against modern PHP.
PHP version ceiling. Doctrine 2.4/2.5 predates scalar type hints, return types, and attributes. On PHP 8.1+ you will hit deprecations and fatals. Either pin PHP 7.4 in Docker or rewrite the bridge against Doctrine 2.15+ with attributes and createAttributeMetadataConfiguration().
Doctrine 2 → 3 breakage. EntityManager::create() was removed in Doctrine 3; you now use new EntityManager($connection, $config). The proxy directory, auto_generate_proxy_classes, and ProxyFactory config also changed. A 2015 bridge will not accommodate this. Plan the rewrite before you plan the upgrade.
Service container lifetime. Doctrine's EntityManager is stateful (identity map, unit of work). It must be a singleton per request/process. A common mistake when wiring bridges manually is registering it as a transient factory — you will get silently split identity maps and entities that appear to change but don't persist, or vice versa. If the bridge binds it correctly, leave it; if you fork, make the singleton binding explicit.
Debugging tips. When $em "does nothing," the usual culprits are: (a) wrong proxy directory permissions, (b) metadata cache in dev mode serving stale reflection data — clear var/cache/doctrine, (c) entities not being flushed because a repository was constructed with a different entity manager than the one your controller used, (d) SQLite path resolving relative to the wrong working directory under the Isolate console.
Config quirks. Bridges of this era often read config from the container at registration time, not resolution time. Changing config after the provider boots has no effect. Always configure Doctrine before booting the provider, and never mutate connection parameters mid-request.
Extension point: intercept the EntityManager factory. If the bridge exposes a single method that constructs the EntityManager, that is the one method to override in your fork (e.g., to attach Doctrine\DBAL\Logging\Middleware for logging, or a Paginator, or event subscribers). Keep that override in your app code, not in the vendored copy, so composer update (or a re-fork) does not erase it.
Do not advertise it as infrastructure. With zero dependents and a decade of silence, treating this package as a stable dependency in a team codebase is a maintenance hazard. If you must use it, document it in your README as "vendored fork, pinned Doctrine 2.x, owned by [team]" so the next developer does not assume upstream support.
Escape hatch. The cleanest long-term move is to replace the bridge with a small application-level DoctrineServiceProvider that you control. That gives you the same DX without the dead-dependency risk, and it is fully testable on modern PHP.
How can I help you explore Laravel packages today?