@honeybadger-io/nextjs/dist/with-honeybadger.d.ts

Next.js integration for Honeybadger

import Honeybadger from '@honeybadger-io/js';
import { NextRequest, NextResponse } from 'next/server';
import type { NextApiRequest, NextApiResponse } from 'next';
type AppRouterHandler = (req: NextRequest | Request, ...args: unknown[]) => Promise<NextResponse>;
type PagesApiHandler = (req: NextApiRequest, res: NextApiResponse, ...args: unknown[]) => unknown;
/**
 * Wraps a handler function with Honeybadger error reporting. Works with App
 * Router route handlers, middleware, and Pages Router API routes.
 *
 * `request_id` / `correlation_id` are read from the `x-request-id` /
 * `request-id` and `x-correlation-id` / `x-amzn-trace-id` headers (generated
 * when absent). When `insights: { enabled: true, http: true }` is configured,
 * a `request.handled` event carrying the ids plus method, path, status and
 * duration is emitted per request.
 *
 * On the Node.js runtime each invocation additionally runs inside
 * `Honeybadger.run(...)`, so context is isolated per request and the ids are
 * seeded onto the event context — merged onto every event emitted during the
 * request, including programmatic `Honeybadger.event(...)` calls. On the edge
 * runtime (browser build, single global store) seeding the shared event
 * context would leak ids between concurrent requests, so programmatic events
 * there don't inherit them.
 *
 * The webpack config-file auto-injection (`honeybadger.*.config.js`) doesn't
 * reach API routes or edge middleware, so pass `config` to configure
 * Honeybadger explicitly there. It's ignored if Honeybadger is already
 * configured (e.g. by the auto-injected file).
 */
export declare function withHoneybadger(handler: AppRouterHandler, config?: Parameters<typeof Honeybadger.configure>[0]): AppRouterHandler;
export declare function withHoneybadger(handler: PagesApiHandler, config?: Parameters<typeof Honeybadger.configure>[0]): PagesApiHandler;
export {};
//# sourceMappingURL=with-honeybadger.d.ts.map