Sentriable Laravel Laravel Package

Getting Started

Start by requiring the package and wiring it into your user model, since that's the primary integration point for a "Sentriable" package.

composer require thedragoncode/sentriable-laravel

1. Publish the config (if the package exposes one) with php artisan vendor:publish --tag=sentriable-config. Read through the config file first — it defines which model attributes get serialized to Sentry and how.
2. Add the Sentriable trait to your authenticatable model (App\Models\User). This is the whole point of the package: it exposes a toSentry() (or similarly named) method that Laravel/Sentry uses to build the user context attached to every event.
3. Confirm the Sentry SDK is already installed and initialized — this package augments the official sentry/sentry-laravel integration, it doesn't replace it.

First use case: throw an exception somewhere inside an authenticated request, open the event in Sentry, and verify the User panel is populated. That's the fastest way to confirm the trait + config are working end to end.

Implementation Patterns

• Trait on the model, data in a method. Keep the Sentry payload definition close to the model (e.g. a toSentry() returning ['id' => ..., 'email' => ...]). This keeps the trait pure and avoids a giant config file of field mappings.
• Trim PII aggressively. Sentry is not the place for full addresses or phone numbers. Restrict the payload to id, an internal username, and maybe org/tenant id. Treat the method as a whitelist, not a blacklist.
• Multi-tenant / multi-auth setups. If you have guards with different user models (admin vs customer), add the trait to each and let each return its own shape. Don't try to force a single schema.
• Context tags over user fields. For things like plan, role, or tenant, prefer adding them as tags via the Sentry SDK (\Sentry\configureScope(...)) rather than cramming them into the user payload — they're filterable and cheaper to search.
• Pair with before_send / before_send_transaction. If you ever need to redact something the trait let through, the Sentry callback is the right place, not a fork or wrapper.
• Testing. In feature tests you can assert the shape returned by the trait method directly without touching Sentry at all — mock the SDK scope, or just unit-test the array shape.

v2.1.0 is a minor bump from v2.0.1 with no documented breaking changes, so existing patterns should carry over; pin ^2.1 and let CI tell you if anything shifted.

Gotchas and Tips

• The trait doesn't fire without an authenticated user. Jobs, console commands, and unauthenticated requests won't carry user context — don't expect the User panel to populate there.
• Config cache. After changing the config, run php artisan config:cache (or config:clear in local dev). It's the most common reason "my changes aren't showing up."
• Serialization surprises. If the method returns a relation or a model instance, you may get far more data than intended. Always cast to scalars/arrays explicitly.
• Debugging what Sentry actually received is easier with SENTRY_DEBUG=true locally or by logging toSentry() output — don't guess from the dashboard.
• Version constraints matter. Sentry SDK v4 vs v3 APIs differ; make sure sentry/sentry-laravel is on a version compatible with the constraint this package declares. Bumping this package alone can be a no-op if the SDK is stale.
• Extension point: the before_send hook and the Sentry event processor pipeline are where you should add custom augmentation that doesn't belong to a single model. Keep the trait dumb and the processors for cross-cutting concerns.
• Don't log sensitive user data in the trait and forget it's also in logs — if the trait output gets dumped during debugging, it leaves the trail you're trying to avoid in Sentry.