Weave Code
Sneaker Laravel Package
squareboat/sneaker
Squareboat Sneaker gives Laravel developers a simple way to preview and test outgoing emails before they reach real inboxes. Inspect rendered mailables in the browser, catch template issues early, and speed up email development without extra tooling.
An easy way to send emails whenever an exception occurs on server.
Frequently asked questions about Sneaker
- What does squareboat/sneaker actually do?
- Squareboat Sneaker hooks into Laravel's exception reporting pipeline and sends an email through your application's configured mailer whenever an exception is thrown. It is a thin, in-process notification layer aimed at small teams who already live in their inbox, not an observability platform. There is no agent, daemon, or external SaaS dependency to install beyond a working mail transport.
- How do I install and set up squareboat/sneaker in a Laravel app?
- Run composer require squareboat/sneaker, then publish the config with php artisan vendor:publish. The service provider is auto-discovered on Laravel 5.5 and above; older versions need manual registration. Wire the package into app/Exceptions/Handler.php, set your recipients and subject prefix, verify the mail transport, and trigger a test exception. Realistically plan for about half a day including staging verification.
- Which Laravel and PHP versions does squareboat/sneaker support?
- The package declares its own Composer constraints, so check the composer.json on the repository or run composer why-not to confirm compatibility with your target framework and PHP versions. Verify this explicitly rather than assuming, because Laravel's exception handler signature and report() semantics have changed across major releases. An outdated constraint set can block your next framework upgrade.
- Does squareboat/sneaker send exception emails synchronously or through a queue?
- Confirm this in the source before approving it for production. If it sends inline, every captured exception adds SMTP latency to a request that is already failing, which can worsen timeouts and user-facing latency. Queued delivery is preferable but depends on a functioning queue worker that may itself be the component that is down.
- How can I test that exception emails actually work before relying on them?
- Publish the config, point delivery at a test recipient or a catcher like Mailtrap, then deliberately throw an exception from a route or via tinker. Check that the message arrives, that the subject prefix and exception exclusions behave as expected, and that a broken mailer does not cascade into a nested failure. Do this in staging, since the mail transport is the usual gating item rather than the package itself.
- Can one recurring bug flood my inbox with hundreds of duplicate emails?
- There is no evidence of built-in fingerprinting, deduplication, or rate limiting in the evaluation, so a single bug in a hot code path can generate hundreds of identical emails. That can exhaust your provider's sending quota and get your sending domain throttled or blocklisted, which then suppresses all transactional mail from that domain. If you adopt the package, add your own throttling in the exception handler or via a wrapper.
- Will exception emails leak request data, PII, or secrets?
- Exception emails typically include stack traces and may include request input and headers depending on how the message is built. Sending that to a plain inbox widens your data exposure surface and can conflict with GDPR, a DPA, or internal data-handling policy. Confirm what redaction support exists and keep recipient addresses out of version control.
- How do I choose recipients and exclude noisy exceptions like validation errors?
- Recipients, subject prefix, and an exception exclusion list are set in the published config file, which is where you suppress noisy classes such as ValidationException. Check the defaults in the repository, since the configuration surface is small and not fully documented. Load addresses from environment variables rather than hardcoding them in config that lives in version control.
- Is squareboat/sneaker a replacement for Sentry, Flare, or Bugsnag?
- No. It sends one email per event with no aggregation, grouping, or fingerprint-based deduplication, so it functions as a stopgap or low-cost safety net. Keep a real APM or error-tracking service for anything beyond a small internal tool with single-digit to low double-digit exceptions per day. Sneaker is best treated as a supplementary notification channel, not an observability platform.
- Is squareboat/sneaker actively maintained, and what are the risks of depending on it?
- The project sits at roughly 219 GitHub stars with a single agency maintainer, which signals a small and possibly quiet project. An unmaintained package that touches the exception handler can become a hard blocker on a Laravel major upgrade, so pin the version and review it as part of dependency checks. Have a fallback plan, such as a short custom handler that mails from report(), if the package stalls.
Weaver
How can I help you explore Laravel packages today?