Salesforce Bundle Laravel Package

Technical Evaluation

Architecture fit

The headline finding for a Laravel shop: this is a Symfony bundle, not a Laravel package. Its value-add is Symfony-specific plumbing — Bundle registration in bundles.php, a DependencyInjection/Extension with a Configuration tree, tagged services, and autowired handlers. Laravel's container reads none of this. The bundle is therefore best understood as two layers:

1. A framework-agnostic(ish) Salesforce REST client (the actual HTTP/SOQL/OAuth logic).
2. A Symfony DI wrapper that lets you inject that client via constructor autowiring.

Layer 2 is worthless to us. Layer 1 may be usable if it has no hard Symfony coupling (likely candidates: Guzzle + PSR-7, possibly symfony/http-client, possibly symfony/options-resolver). The assessment hinges on a source read of composer.json and the client classes — not on the README, which is thin.

Integration feasibility

Feasible but not turnkey. Two paths:

• Path A (recommended): Depend on the underlying REST client directly (or vendor a fork of it) and wire it in a hand-written SalesforceServiceProvider with a config/salesforce.php. Roughly 1–3 days of engineering plus a sandbox PoC. This discards the only part of the package that was "productized."
• Path B (not recommended): Install Symfony's DI/Config/HttpKernel components alongside Laravel and boot the bundle manually. This buys a second container inside our container, a duplicate config subsystem, and version-conflict exposure with Laravel's own Symfony component pins. Maintenance cost is permanent; benefit is zero.

Technical risk — elevated

• Abandoned. Last release 2020-11-25, ~4–5 years stale. Zero dependents and 11 stars means no downstream validation, no issue triage, no security patching.
• PHP/Symfony constraint drift. A 2020 release likely pins PHP 7.x–8.0 and Symfony 4/5, plus possibly Guzzle 6. Our Laravel 10/11/12 baseline (PHP 8.2/8.3) will almost certainly produce Composer conflicts and, if forced through with --ignore-platform-reqs, runtime deprecations at minimum.
• Salesforce API version staleness. The hardcoded API version is likely v45–v50. Salesforce retires API versions on a ~3-year rolling window; retired versions return 400 INVALID_VERSION. This is not a hypothetical — it is a scheduled outage.
• Coverage gaps. Expect CRUD + SOQL only. Bulk API 2.0, Composite, Platform Events / Change Data Capture, and streaming are probably absent, and those are the APIs that matter at volume.
• Mitigating factors: MIT license (fork-friendly), small surface area (easier to own than to replace), and the bundle layer being trivially disposable.

Key questions to resolve before committing

1. What is the actual underlying client package, and does it function without Symfony components?
2. Which Salesforce API version is hardcoded, and can it be overridden by config?
3. Does it handle OAuth 2.0 JWT bearer flow and refresh-token rotation, or only username/password (which Salesforce is actively deprecating)?
4. Does it support Bulk API 2.0, Composite, and external-ID upsert? If not, we are writing that ourselves.
5. What volume and object mix do we need — 500 records/night, or 500k? That single answer determines build-vs-adopt.
6. Is omniphx/forrest (Laravel-native, comparable maturity) or phpforce/salesforce-rest-api materially better, or is a 200-line Saloon/Guzzle client with contract tests the honest answer?

Integration Approach

Stack fit

Poor out of the box, acceptable after stripping the bundle layer. Assume Laravel 11/12, PHP 8.3, Composer 2. Expect the package's symfony/* constraints to conflict with Laravel's. Plan for a fork rather than a composer require.

Migration path

1. Fork to ourorg/salesforce-client (MIT permits this). Delete the DependencyInjection, Resources/config, and *Bundle classes; keep the client, auth, and query builder.
2. Relax/upgrade platform constraints; bump the Salesforce API version to a currently supported one (e.g., v62+) and make it config-driven, not constant-driven.
3. Expose it through App\Providers\SalesforceServiceProvider binding a SalesforceClient interface; config in config/salesforce.php, credentials in env / secrets manager.
4. Back it with Laravel's cache for access tokens (short TTL, keyed by org + user) rather than in-process token state.
5. Add an outbound adapter layer so business code depends on our interface, not the vendor's method signatures — this is what lets us swap to Bulk API or a different client later without touching domain code.

Compatibility

• Pin the API version explicitly in config; add a scheduled CI check that hits a sandbox and fails on version-deprecation warnings.
• Run against a Salesforce Developer sandbox from day one; do not discover auth quirks in production.
• Verify behavior under PHP 8.3 with E_ALL; expect dynamic-property and null-to-non-nullable deprecations in a 2020 codebase.

Sequencing

Realistic total: 5–8 weeks for one engineer, of which the package saves perhaps one week.

Operational Impact

Maintenance

Effectively we own this code from day one. There is no upstream to patch. Budget 1–2 engineer-days per quarter for dependency bumps, Salesforce API version advancement, and PHP upgrades — plus a hard deadline each time Salesforce announces a retirement. Treat the fork as first-class internal code: owned in CODEOWNERS, covered by tests, included in the PHP upgrade rotation.

Support

No vendor, no community (0 dependents, 11 stars). Escalation path is "the engineer who read the source." Mitigate with a written ADR capturing why we forked, what we changed, and what would trigger a replacement. Avoid single-person dependency — two engineers should be able to read the client.

Scaling

This is where the package is most likely to fail us, because a synchronous per-record REST client does not scale against Salesforce governor limits:

• Daily API call allotment (edition-dependent, ~15k–100k+) — synchronous loops burn this fast.
• Concurrent long-running request cap (~25 per org) — a naive parallel queue worker pool will get REQUEST_LIMIT_EXCEEDED.
• Batch sizing — use Composite for ≤25 records, Bulk API 2.0 for anything above a few thousand. If the package lacks Bulk, that is a build item, not a nice-to-have.
• Push all writes through Laravel queues with rate limiting (Redis::throttle), not request-cycle calls.
• Use external-ID upsert, never create-then-check — it is the difference between idempotent retries and duplicate records in the CRM.

Failure modes to design for

Ramp-up

A mid-level PHP engineer reaches productivity in 1–2 weeks, most of it spent on Salesforce's auth and limits model rather than the package itself. The TPM-level cost is the discovery work — sandbox provisioning, API entitlement confirmation with the Salesforce admin, and the build-vs-adopt decision — which should be front-loaded into the spike.

Recommendation: Do not adopt this package as-is. Use it as a reference implementation and possible source for the client layer, forked and narrowed, behind our own interface. The low score and low opportunity signal (1.52 / 21.84) are consistent with what the code review will show: a small, dated, unmaintained wrapper whose only integrated feature is the one we cannot use. The decision that actually matters is build-vs-adopt at the client layer, and that should be settled by the two-day sandbox spike, not by the star count.