Todoist Laravel Package

Technical Evaluation

Architecture fit. This is a thin adapter package: a Laravel Socialite driver that owns the Todoist OAuth2 handshake and normalizes the Todoist profile into Socialite's User contract. It does not own Todoist API calls after token issuance. That boundary is correct if Todoist is being added as an identity/authorization provider alongside existing Google/GitHub/email login. If the roadmap actually requires task/project sync, this package covers only the auth slice and a separate API client will still be needed — size the decision accordingly.

Integration feasibility. High. The standard path is composer require socialiteproviders/todoist, register the SocialiteWasCalled listener, add a todoist block to config/services.php, and add redirect/callback routes. If the app already runs Socialite for another provider, this is a near-copy of an existing pattern and carries little novel risk.

Technical risk. The release artefact is the risk, not the architecture. Version 4.3.0 ships with a bare compare URL — no enumerated changes, no migration notes, no security callouts. Semver implies no breaking change, but that is an inference from the version number, not a statement in the notes. Provider packages historically change at exactly the layer that matters here: endpoint constants, default scopes, and user-field mapping. A silent minor bump in any of those breaks token exchange at runtime. Treat the 4.2.0→4.3.0 diff as unread until someone has actually read it.

Key questions.

• What files does the 4.2.0→4.3.0 diff touch — specifically anything under the driver's endpoint, scope, or user-mapping code?
• Which Socialite major does 4.3.0 require, and does that match the version currently pinned in the app?
• Any shift in PHP (8.3/8.4) or Laravel (11/12) constraints that collides with our platform baseline?
• What is the maintenance signal — commit cadence, open PR age, prior release date?
• Are the default requested Todoist scopes the minimum the product needs, or is the integration over-asking for permissions at consent time?

Integration Approach

Stack fit. Laravel-idiomatic. No custom container wiring, no service provider surgery beyond the standard event listener. Changes are confined to config/services.php, the event registration, two routes, and one controller.

Migration path. Greenfield for new integrations. If replacing a hand-rolled Todoist OAuth implementation, keep existing token column names and encryption scheme and swap only the handshake — that preserves stored credentials and avoids forcing every connected user to re-consent.

Compatibility. Run composer why-not socialiteproviders/todoist 4.3.0 before merging. The failure mode for a Socialite contract mismatch is a runtime Driver [todoist] not supported exception, not an install-time error, so a clean composer require is not evidence of compatibility. Pin the exact version in composer.lock.

Sequencing.

1. Read the diff; confirm nothing touches token, user, or endpoint handling.
2. Install on a branch and run the existing auth test suite.
3. Complete a full OAuth round-trip in staging against a non-production Todoist app registration.
4. Test the consent-denied and scope-revoked paths, plus token refresh behaviour.
5. Ship behind a flag if Todoist login is user-facing rather than internal-only.

Keep client ID/secret in environment variables; nothing provider-related should be committed.

Operational Impact

Maintenance. Small surface area, but this is a community-maintained package in the SocialiteProviders org with no commercial backing. Budget for the possibility of forking or vendoring the driver. The mitigating factor is that the driver is only a few hundred lines and the exit cost is genuinely low — that is the primary reason to accept the dependency at all.

Support. No vendor SLA. Upstream issue tracker only. Write down the fork procedure now, while it is cheap, rather than during an auth outage.

Scaling. Negligible. The package participates only in the OAuth handshake, so it adds no per-request overhead and scales with login volume — not a meaningful constraint at any plausible size.

Failure modes.

• Todoist OAuth outage → Todoist login fails; the app must degrade cleanly to email/password or another provider rather than dead-ending at the callback.
• User revokes access in Todoist → token calls return 401; a re-consent path must exist or affected users are stuck.
• Socialite major upgrade → driver contract breaks silently until the first login attempt.
• A minor release altering endpoint constants → hardest to detect; the staging round-trip in CI is the only reliable catch.

Ramp-up. Half a day for a Laravel developer already fluent in Socialite. One to two days if the same person is also building the post-auth Todoist API layer, which the package does not provide.