Sdk Laravel Package

Technical Evaluation

Architecture fit. sentry/sdk is a Composer metapackage: it contains no PHP classes, no service provider, no facade, no config stub, no auto-discovery entry. Its entire behavior is a composer.json require block that pulls sentry/sentry plus a recommended PSR-18/PSR-7 HTTP client stack. Architecturally it is the "batteries-included" selector for the core SDK's transport layer, not an integration surface. For a Laravel codebase the correct architectural unit is sentry/sentry-laravel (which owns the service provider, config/sentry.php, exception handler hooks, queue/command instrumentation); sentry/sdk is at best a transitive artifact beneath it. Treat any proposal to "add sentry/sdk" as a dependency-graph question, not an architecture decision.

Integration feasibility. Trivial to install and trivially reversible — there is nothing to wire. The only real integration work is confirming who else already requires it: composer why sentry/sdk / composer depends sentry/sdk will typically show sentry/sentry-laravel or sentry/sentry as the consumer. If the metapackage is already present transitively, direct adoption adds nothing. If it is absent, adding it explicitly is a no-op at runtime and only introduces a version constraint we now own.

Technical risk.

• Version lockstep. The metapackage pins the core SDK with a self-referential constraint, so sentry/sdk minor lines and sentry/sentry minor lines move together. A Dependabot bump of sentry/sdk can force an unintended core SDK upgrade, and vice versa a held-back core SDK can make a standalone sentry/sdk update unresolvable.
• HTTP client collision. It drags in a Guzzle/curl-client implementation. Laravel apps usually already carry Guzzle (via laravel/framework's HTTP client) and frequently a PSR-18 implementation. Two transports in the same dependency graph is a conflict surface, not a runtime bug, but it produces composer update deadlocks that get debugged at the worst time.
• Staleness signal. Last release 2023-12-04 against an actively developed core SDK. For a metapackage this is expected — its whole purpose shrank as sentry/sentry 4.x grew its own curl-based HttpTransport and stopped needing an external client. But it means the package is a lagging indicator and a plausible future abandoned marker.
• Signal quality. 327 stars / 0 listed dependents / score 1.875 is not evidence of poor quality; it is evidence of invisible quality. Nearly every consumer pulls it transitively and stars the main repo instead. Do not read the low score as a red flag, and do not read it as validation either — it carries almost no information.

Key questions for the owning team.

1. Which sentry/sentry major is in the lockfile, and does our sentry/sentry-laravel version still require sentry/sdk at all?
2. Do we already ship an approved PSR-18 client, and does the metapackage's choice conflict with it?
3. Are we relying on a custom transport (e.g., routing events through Laravel's HTTP client for egress control or proxying), in which case the "recommended client" is dead weight?
4. Who owns Sentry version hygiene — is there a named owner for the observability dependency set?
5. Does our egress/proxy configuration require the curl transport specifically, or is any PSR-18 client acceptable?

Integration Approach

Stack fit. Install sentry/sentry-laravel (Laravel 9–11) or sentry/sentry (non-Laravel services, queue workers, CLI tooling). Let the metapackage resolve transitively and do not add a direct require on sentry/sdk unless we are deliberately overriding the transport. Constrain at the integration layer, not the metapackage layer.

Migration path.

• Inventory: composer show sentry/*, composer why sentry/sdk, composer why guzzlehttp/guzzle.
• If on the 3.x line of sentry/sentry-laravel, the metapackage is a hard requirement; upgrading to 4.x relaxes that and is the cleanest way to remove the dependency from our surface area.
• If removal is desired, upgrade the integration package first, then confirm composer why sentry/sdk returns empty before deleting any lockfile entry.
• Never hand-edit the lockfile; drive it through constraint changes in composer.json and a full composer update --with-dependencies in a dedicated PR.

Compatibility.

• PHP 7.4/8.x constraints on older metapackage lines can pin the whole graph on PHP 8.3+ projects — check before upgrading the runtime.
• Guzzle 6 vs 7 is the classic conflict; Laravel 10/11 already expects Guzzle 7, so align there.
• Composer 2 only; no plugin hooks, so no Composer 2.2 allow-plugins friction.
• No Laravel package discovery, so package:discover is unaffected either way.

Sequencing.

1. Confirm the observability owner and current DSN/transport configuration.
2. Inventory the Sentry dependency subgraph and record the resolved versions.
3. Upgrade sentry/sentry-laravel to the target major; observe whether sentry/sdk drops out.
4. Only if it remains and conflicts, explicitly pin the compatible sentry/sdk line with a dated comment.
5. Canary in staging: verify event delivery with php artisan sentry:test, confirm sampling rates, watch for transport errors in the app log.
6. Roll to production during low error volume; compare event counts against baseline before/after.

Operational Impact

Maintenance. Near-zero direct maintenance and near-zero code surface — there is nothing to patch, no config to drift, no migrations. The inherited maintenance is upstream release cadence and the fact that a stale metapackage can silently gate the core SDK's version. Budget for it in the same review cycle as the rest of the observability stack; do not give it its own Dependabot lane, or the team will spend review cycles on PRs that are pure version arithmetic.

Support. OSS-only. Sentry's commercial relationship covers the SaaS ingest and UI, not SDK defect SLAs. Escalation is GitHub issues on getsentry/sentry-php; the metapackage repo itself is a thin manifest. If event delivery is business-critical (e.g., alerting feeds on-call), document a fallback path — logs, APM, or a secondary error tracker — because our support leverage over this layer is thin and slow.

Scaling. The metapackage has no runtime footprint; scaling questions belong to the transport and sampling config it selects: traces_sample_rate, sample_rate, max_breadcrumbs, and whether the transport is synchronous. The high-leverage decision is a non-blocking transport for web requests so a slow or unreachable Sentry ingest endpoint cannot add latency to user-facing requests. Watch event volume cost, not package performance.

Failure modes.

• Silent event loss — missing/blank SENTRY_LARAVEL_DSN in one environment turns reporting into a no-op with no startup error.
• Synchronous transport — Sentry ingest latency or outage adds tail latency to every request; the failure is invisible in application logs.
• Dependency deadlock — a Guzzle/PSR-18 constraint conflict blocks a deploy at composer install time, typically during an unrelated upgrade.
• Lockstep drift — a standalone metapackage bump forces an unwanted core SDK version jump; error payload shape and options can change across majors.
• Double instrumentation — app-level Guzzle middleware plus the SDK's own transport produces duplicated or attributed-wrong spans.
• Sampling misconfiguration — 100% trace rate in production produces cost overrun and ingest throttling that reads as "Sentry is dropping events."

Ramp-up. Low for application engineers — there is no API to learn, and Sentry::captureException() / captureMessage() are self-evident. The actual ramp-up cost is conceptual and lands on whoever owns the dependency graph: understanding Composer resolution, why the metapackage exists, and which layer to constrain when things conflict. Expect half a day for a senior engineer to be productive here, and treat that as the real cost of the package — not the install.