Ldaprecord Bundle Laravel Package

Technical Evaluation

Architecture fit

• Unchanged first-order finding: this is a Symfony bundle, not a Laravel package. If the target application is Laravel, this dependency is irrelevant — use directorytree/ldaprecord-laravel. v4.0.0 does nothing to alter that.
• For a Symfony target, the fit is idiomatic (bundle registration, config/packages/*.yaml, autowired services) and now better aligned with the current ecosystem: v4.0.0 moves to LdapRecord v3 and raises the floor to PHP 8.1 / Symfony 6.1.
• The value remains thin: DI registration plus a config tree. The real work lives in directorytree/ldaprecord, which is actively maintained.
• The bundle still provides connection/manager objects only. It is not a Symfony Security user provider or authenticator — that glue remains ours to write.

Integration feasibility

• Two of the three previously decision-critical unknowns are now answered: LdapRecord v3 and PHP 8.1+ / Symfony 6.1+. That converts a multi-day constraint-resolution gamble into an install-and-wire exercise.
• New hard constraint: Symfony 5.4 LTS is excluded. Any estate still on 5.4 cannot adopt v4.0.0 and must stay on v3.0.0 (LdapRecord v2), which is now an unmaintained branch. This is the main new decision point.
• Symfony 7.x support is still unstated in the notes. Symfony 6.1 is already EOL, so the practical target is 6.4 LTS or 7.x — verify the constraint graph against whichever we run before committing.
• Compounded upgrade cost: adopting v4.0.0 forces LdapRecord v2 → v3, which carries its own API breaks in addition to the bundle change. If we already have LdapRecord v2 query code, these two migrations land in the same release and must be sequenced together.
• Directory target still matters more than the bundle: AD vs OpenLDAP differ in schema, paged results, referrals, and size-limit behavior. None of that is abstracted away here, and the release notes give no indication it changed.

Technical risk

• The staleness finding is materially softened: a release after roughly 20 months is direct evidence the maintainer is responsive, and it lands the package on a current LdapRecord major. That neutralizes the version-lock risk that previously dominated.
• Breaking change introduced: the bundle namespace moves from Iter8\Bundle\LdapRecordBundle\Iter8LdapRecordBundle to Iter8\LdapRecordBundle\Iter8LdapRecordBundle. This breaks bundles.php registration, any services.yaml aliasing, and any use statement referencing bundle classes. Cost is minutes to fix, but it is a real major-version break and will silently no-op if a stale bundle class is left registered.
• Adoption signal is unchanged: 3 stars, no evidence of dependents outside the author. Still effectively a single-vendor wrapper (iter8-au) around a library that moves independently.
• Bus factor remains roughly one, and the release notes still show no CI or test evidence — a single PR from a contributor and a version bump. The v4 tag being correct at release time is not the same as it being covered.
• Overall risk profile: net improvement, but the recommendation to fork-or-inline is not overturned — the surface area is still small enough that owning it costs less than tracking it.

Key questions

• Does the manifest permit Symfony 7.x, or does it cap at 6.x? This determines shelf life and is the single most important open item.
• Is there a supported maintenance branch for v4.0.0 consumers on Symfony 5.4, or is v3.0.0 now dead? If we have any 5.4 systems, we are stranded.
• What in LdapRecord v3 breaks relative to v2, and does the bundle expose any of those surfaces (connection options, query builder, pagination)?
• Is there now any CI, or a test suite at all? The release notes give no signal either way.
• Does it connect eagerly at container boot or lazily on first use?
• Does it support multiple connections and per-connection options (TLS, protocol, timeouts, page size)?
• Can we still satisfy the requirement with ~50 lines of our own service definitions instead? This remains the strongest fallback.

Integration Approach

Stack fit

• Symfony 6.4 LTS / 7.x → evaluate with a much higher prior than before; the version alignment is now the strongest argument for the package.
• Symfony 5.4 LTS → blocked on v4.0.0. Either upgrade the platform or drop to v3.0.0 and accept an EOL LdapRecord v2 line. Neither is attractive; prefer platform upgrade or inline the service definitions.
• Laravel → reject and use the first-party integration. Mixed estate → use ldaprecord/ldaprecord core directly in both and skip the bundle entirely; this remains the lowest-regret option and the v4 release does not change it.
• Assume PHP 8.1+ / Symfony 6.4 LTS as the baseline. On older Symfony the package's new floor is moot — the platform is the constraint, not the bundle.

Migration path

• From bundle v3.0.0 → v4.0.0, the migration is two changes performed together, in one branch:
  1. Namespace swap in config/bundles.php and any services.yaml references or use statements.
  2. LdapRecord v2 → v3 API migration for any query/filter code we own.
• Do the namespace change and the LdapRecord upgrade as separate commits so a failure is attributable. Verify bin/console debug:container resolves the new bundle class before touching any LDAP logic.
• Spike branch first: install, wire one connection to a containerized OpenLDAP and a test AD, exercise bind / search / create / modify.
• Keep the bundle behind an internal interface (e.g. DirectoryGateway) so it remains a swappable implementation detail. The v4 namespace break is exactly the kind of churn that abstraction absorbs.
• If replacing an existing auth path, run in parallel: new provider reads the directory, legacy path stays authoritative, results diffed before cutover.

Compatibility

• Pin exact versions and commit composer.lock; add a CI job that upgrades Symfony minors against the bundle to surface breakage early rather than at deploy time. Given the release cadence, we will not get warning from upstream.
• Verify the Symfony 7 constraint before adopting. If it caps below 7, plan the inline/fork exit now rather than at the next LTS upgrade.
• Validate attribute mapping and search filters against real directory data, not fixtures — sAMAccountName/memberOf vs uid/groupOfNames. LdapRecord v3 may change filter or pagination semantics; re-test rather than assume.
• If constraints conflict: fork under our namespace, or drop the bundle and register LdapRecord services ourselves. The latter remains the preferred fallback given the trivial surface area.

Sequencing

1. Constraint check: does v4.0.0 resolve on Symfony 6.4 LTS and 7.x? (hours) — go/no-go gate.
2. Decide the platform question: are any consumers on Symfony 5.4, and if so do they upgrade or stay pinned at v3.0.0?
3. Spike: namespace migration plus LdapRecord v2→v3 upgrade against both AD and OpenLDAP.
4. Decide: depend / fork / inline (~50 LOC). Fork-or-inline remains defensible and arguably preferable.
5. Build the internal abstraction plus the Symfony security user provider/authenticator.
6. Parallel-run, cut over behind a feature flag, keep the legacy path warm for one release.

Operational Impact

Maintenance

• The 20-month gap is closed, but the cadence pattern — one release, one contributor, no visible CI — should be treated as best-effort rather than a maintenance commitment. Budget one to two days per quarter to track Symfony and LdapRecord upgrades.
• The v4 release is a reminder that this package will take breaking changes on its own schedule. Every adoption should be assumed to need a planned migration every 12–24 months.
• Fork-or-inline is still the recommended posture. v4.0.0 makes the dependency safer to adopt today but does not make it safer to depend on indefinitely; a fork now starts from a current base rather than a stale one, which is strictly better than the previous position.

Support

• No commercial support; community-only via issues on a 3-star repo. An internal owner with LDAP + Symfony DI experience is mandatory. The one recent contributor PR is a mildly positive signal for community responsiveness but is not a support channel.
• Escalation path is unchanged: read LdapRecord docs and patch our fork. The namespace change makes patching slightly more annoying (all references move), nothing more.

Scaling

• Connections are cheap; the real risks are per-request binds and unpaged searches against large directories. Enable paging, cache slow-changing reads, and use a service-account connection rather than binding per request.
• LdapRecord v3's query API may alter pagination or lazy-loading behavior; re-benchmark paged searches after the upgrade rather than carrying forward v2 assumptions.
• Long-running workers (Messenger, RoadRunner, Swoole) will surface stale connections after idle timeouts. Reconnect and health-check logic almost certainly does not exist in the bundle and must be built.

Failure modes

• LDAP unreachable at boot → container-wide failure if connections are eager. Enforce lazy connection. Unverified in v4.0.0.
• Namespace mismatch after upgrade → bundle silently not registered, or a class-not-found at container compile. Loud if compile fails, quiet if an old registration lingers. Catch it in CI, not in production.
• TLS/cert misconfiguration or an expired bind-account password → auth outage with opaque errors. Needs health checks and explicit alerting.
• Silent partial results from size-limit or referral handling → incorrect authorization decisions. High severity in a security context. Re-verify behavior on LdapRecord v3, since this is exactly where a major upgrade can shift semantics.
• No client-side deadline → hung web requests during directory latency.
• Directory becomes a hard auth dependency; the degrade behavior (deny vs. cached fallback) must be an explicit product decision, not an emergent one.

Ramp-up

• Low and slightly improved. A Symfony developer is productive in about a day; LdapRecord's Eloquent-style API is familiar, and v3 is the version current documentation describes — an advantage over the previous state, where docs and pinned version diverged.
• The learning curve remains LDAP itself — filters, DNs, schema quirks — not this package. Add a one-hour briefing on the namespace migration for anyone touching bundles.php or service config.