Connect Bundle Laravel Package

Product Decisions This Supports

• Dependency due-diligence and vendor-risk policy. This package is a useful reference case for a "do not adopt" rule: archived repository, last release 2019-09-25, 34 stars, 0 dependents. It supports codifying a policy that scores packages on maintenance recency, archive status, dependent count, and upstream service viability before they enter the stack.
• Build vs. buy for authentication. It informs the decision to standardize social/SSO login on a maintained abstraction rather than a single-vendor integration. For a Laravel product that means Laravel Socialite plus a maintained provider package; for Symfony, the core security bundle or a maintained OAuth bundle.
• Roadmap hygiene and migration budgeting. If any internal app still references this bundle, the PM decision is "schedule replacement, do not extend." It belongs in a deprecation backlog item, not a feature roadmap.
• Incident and lifecycle risk framing. Illustrates the failure mode of coupling a login flow to a third-party identity service that can be retired underneath you — a business continuity concern, not just a code concern.
• Not a feature enabler. There is no user-facing capability this package unlocks today; the SensioLabs Connect developer-profile service it integrated with is no longer a viable identity provider.

When to Consider This Package

Consider it only in one narrow situation: you are auditing or decommissioning a legacy Symfony application that already has sensiolabs/connect-bundle in its composer.json, and you need to understand what it was doing before removing it.

Criteria that would normally justify adoption — and which this package fails:

• Maintenance: active releases within the last 12–18 months. Failed (2019).
• Project health: not archived, has a security policy, responsive issue tracker. Failed (archived).
• Ecosystem signal: non-trivial dependent count and real-world usage. Failed (0 dependents, 34 stars).
• Framework fit: it is a Symfony bundle, not a Laravel package — it does not integrate with Laravel's service container, auth guards, or Socialite. Failed for a Laravel codebase.
• Upstream viability: the identity provider it depends on must still exist and be supported. Failed.

Look elsewhere in essentially every case. For Laravel, use Laravel Socialite or a maintained OIDC/OAuth2 client (league/oauth2-client and its provider packages) against providers you control or that are contractually durable — Auth0, Keycloak, Cognito, Entra ID, or equivalent. For Symfony, use the core Security bundle or a maintained OAuth bundle. The MIT license is the only genuinely reusable asset here; if a specific integration behavior is still wanted, fork the logic rather than depend on the package.

How to Pitch It (Stakeholders)

To executives: We evaluated sensiolabs/connect-bundle and recommend against adoption. It is an archived, unmaintained Symfony bundle whose last release was in 2019, with negligible community adoption, and it integrates with a third-party developer-identity service that is no longer viable. Adopting it would put our sign-in flow on an unsupported dependency with no security patching path. The cost of adoption is low today and the cost of failure — a broken login flow — is high and reputationally visible. Recommended decision: add it to the dependency blocklist, and if any legacy service still uses it, fund a small migration to a maintained authentication library.

To engineering: Treat this as a deprecation, not a candidate. It is Symfony-specific, so it is not usable in a Laravel application without effectively rewriting it. Replace any existing usage with Laravel Socialite or a standard OIDC client, and keep authentication on open protocols with swappable providers so a vendor retirement is a config change rather than an incident. Add an automated check — archive status, last-release age, dependent count — to CI so packages like this are flagged before they reach composer.json.