- Can I install mhujer/javascript-error-handler-bundle in a Laravel app?
- No. mhujer/javascript-error-handler-bundle is a Symfony bundle: it ships a Bundle subclass, DI container wiring, and Twig resources, and has no service provider, facade, or publishable config. Composer can pull it into a Laravel project, but nothing will register or boot it. Treat it as prior art for the pattern rather than a dependency.
- What does this bundle actually do?
- It installs a window.onerror hook that captures uncaught JavaScript errors and POSTs the message, source file, line number, and stack trace to a bundle-provided controller endpoint. That endpoint forwards reports to Monolog on a configurable channel and level, and the bundle supports ignore rules by message or source plus configurable filtering and reporting behaviour. Setup is enabling the bundle and including the supplied script via Twig.
- How do I install and enable it in Symfony?
- Enable the bundle in your Symfony kernel or bundles config, then include the bundle's JavaScript asset in your Twig layout so the handler loads on the pages you want covered. There is no publishable config file or artisan command; all wiring is Symfony-specific. In a Laravel app you would be copying the endpoint and JS by hand, which is not a supported path.
- Does it support Laravel 10, Laravel 11, or PHP 8.1+?
- There is no Laravel support at all. The bundle dates from the Symfony 2.x/3.x era with likely PHP 5.x and Twig 1.x constraints that will not resolve cleanly against PHP 8.1+ or Laravel 10 and 11. Treat it as abandoned code on day one.
- How do I port this JavaScript error handler to Laravel?
- Extract the browser-side window.onerror logic, replace the alert dialog with a non-blocking sink such as fetch or navigator.sendBeacon to a rate-limited Laravel route, and load the module through Vite with a Blade partial or the @vite directive. Gate reporting behind APP_DEBUG or a dedicated env flag, add a dedupe guard, and review it for CSP compliance. Expect roughly 0.5 to 1.5 engineer-days; rewriting from scratch costs about the same and gives you code you own.
- Why do I only see "Script error." and what errors are missed?
- Browsers replace details of cross-origin script errors with the opaque message Script error., so you get a report but no message, source, or stack unless the script is served with crossorigin and matching CORS headers. Beyond that, window.onerror misses resource load failures and unhandled promise rejections entirely. Sparse, misleading signal can be worse than no signal if anyone makes decisions on it.
- Is it safe to show JavaScript errors to end users in production?
- The bundle's browser handler surfaces errors in alert() dialogs, which block the main thread and are user-hostile; in an error loop the reporting mechanism can amplify an incident into an outage. Rendering messages and stack traces in a dialog also risks information disclosure of internals to end users. If you need production front-end telemetry, use a vendor SDK or a non-blocking in-house endpoint instead.
- Does this work with a strict Content-Security-Policy?
- Likely not as-is. Inline-script inclusion patterns conflict with a strict script-src policy without nonces or hashes, which is a common enterprise blocker. Any port should load the handler from a bundled Vite asset and be validated against your CSP before rollout.
- How would I test a ported Laravel JavaScript error handler?
- Unit-test the JS module by stubbing window.onerror and asserting the payload shape, then feature-test the Laravel endpoint with a route test that asserts validation, rate limiting, and log-channel assertions. For the bundle itself there is no Laravel test harness, so you cannot meaningfully PHPUnit it inside a Laravel app. Browser-level tests with Playwright or Dusk can confirm the script loads under your CSP and reports correctly.
- What are the alternatives, and is this package maintained?
- For production front-end telemetry, evaluate Sentry, Bugsnag, or Rollbar, or build a small owned sendBeacon endpoint behind a rate-limited route. The bundle itself is effectively unmaintained: one star, zero dependents, a Symfony 2.x/3.x-era codebase with no upstream fixes or CVE monitoring, though its MIT license is legally clean. Frame it as a reference implementation for capturing client-side errors, not a component to depend on.