refactor(error): consolidate error package from sentry and utils#126
Merged
gaboesquivel merged 4 commits intomainfrom Mar 8, 2026
Merged
refactor(error): consolidate error package from sentry and utils#126gaboesquivel merged 4 commits intomainfrom
gaboesquivel merged 4 commits intomainfrom
Conversation
- Rename packages/sentry to packages/error - Move packages/utils/src/error into packages/error/src/utils - Add no-DSN fallback: log errors when reporting backend not initialized - Rename initSentry to initErrorReporting, tech-agnostic API - Update env vars: ERROR_REPORTING_DSN, ERROR_REPORTING_ENVIRONMENT - Add Next.js error reporting setup (error-reporting.*.ts, sentry shims) - Update Fastify to use initErrorReporting from @repo/error/node - Update all imports: @repo/sentry -> @repo/error, @repo/utils/error -> @repo/error - Update docs, cursor rules, and skills for @repo/error - Recommend GlitchTip in docs; Sentry also works (same DSN format)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughReplaces the Sentry-focused package with a new Changes
Sequence Diagram(s)sequenceDiagram
participant Browser as Browser (client)
participant ClientInit as initErrorReporting (client)
participant Reporting as Reporting Backend
participant Next as Next.js App (server/edge)
Browser->>ClientInit: module-load initErrorReporting(dsn, env)
ClientInit->>Reporting: configure client (dsn, env)
Note right of Reporting: client initialized
Browser->>Reporting: captureError(options) (client-side)
Reporting-->>Browser: ack (async)
Browser->>Next: request -> server error
Next->>Reporting: captureError(options) (server-side)
sequenceDiagram
participant Fastify as Fastify server
participant ErrorCore as createCaptureError
participant Logger as App Logger
participant Reporting as Reporting Backend
Fastify->>ErrorCore: captureError({error,label,logger,report:true})
ErrorCore->>Reporting: captureException(normalizedError,{tags,contexts,level})
Reporting-->>ErrorCore: success / failure
ErrorCore->>Logger: on failure -> logger.error(...)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
.cursor/skills/wagmi-v3/SKILL.md (1)
570-576:⚠️ Potential issue | 🟡 MinorStale comment references Sentry instead of the new error package.
The comment on line 570 says "Log to Sentry" but the import now uses
@repo/error/nextjs. Update the comment to be consistent with the new error reporting abstraction.📝 Proposed fix
- // Log to Sentry + // Log to error reporting captureError({🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursor/skills/wagmi-v3/SKILL.md around lines 570 - 576, Comment is stale: change the "Log to Sentry" comment above the captureError call to reference the new error package instead of Sentry. Update the comment to something like "Report error via `@repo/error/nextjs`" (or simply "Report error") so it matches the use of captureError from `@repo/error/nextjs`; keep the captureError({ code: 'TRANSACTION_ERROR', error, label: 'Contract Write', data: { request } }) call unchanged.apps/fastify/src/plugins/error-handler.ts (1)
79-86:⚠️ Potential issue | 🟡 MinorStale comments still reference "Sentry" instead of the generic error reporting abstraction.
The import has been updated to
@repo/error/node, but the comments at lines 79 and 86 still mention "Sentry". Update them for consistency with the new package name.📝 Proposed fix
- // Redact sensitive data before sending to Sentry + // Redact sensitive data before sending to error reporter const sanitizedHeaders = redactHeaders(request.headers as Record<string, unknown>) const sanitizedBody = redactBody(request.body) // Map status code to error code const errorCode = mapHttpStatusToErrorCode(statusCode) - // Report to Sentry (non-blocking) + // Report to error service (non-blocking) captureError({🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/fastify/src/plugins/error-handler.ts` around lines 79 - 86, Update the stale comments that mention "Sentry" to reference the generic error reporting abstraction (imported from `@repo/error/node`) for consistency; specifically change the comment above the sanitization lines near the calls to redactHeaders and redactBody and the comment before the reporting call (around mapHttpStatusToErrorCode usage) to mention the generic error reporter or error-reporting abstraction instead of "Sentry", ensuring the comments align with the imported module and the functions redactHeaders, redactBody, and mapHttpStatusToErrorCode.README.md (1)
57-57:⚠️ Potential issue | 🟡 MinorStale reference to "sentry" in dev command description.
Line 57 still lists
sentryin the dev command, but the package has been renamed toerror. Update for consistency.📝 Proposed fix
- - `dev` — Start dev (core, react, sentry, utils, fastify, next) + - `dev` — Start dev (core, react, error, utils, fastify, next)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` at line 57, The README's dev command description still references the old package name "sentry"; update the string in the dev command entry (the line showing the `dev` command description that currently reads "`dev` — Start dev (core, react, sentry, utils, fastify, next)") to replace "sentry" with "error" so it reads "`dev` — Start dev (core, react, error, utils, fastify, next)"; ensure any other occurrences of "sentry" in README command lists are similarly updated for consistency.apps/docu/content/docs/development/packages.mdx (1)
19-25:⚠️ Potential issue | 🟡 MinorInconsistency:
@repo/errorlisted as subpath-only but also has root exports.Line 21 lists
@repo/error/*as a "Subpath-only package" with "no root export", but lines 174 and 182 document@repo/erroras a valid root import for utilities likegetErrorMessageandtryCatch. This creates confusion about the package's import structure.Consider either:
- Moving
@repo/errorto the "Mixed" category (like@repo/utils)- Or clarifying that the root export is for utilities only while platform-specific code requires subpaths
📝 Suggested fix - move to Mixed category
- **Subpath-only packages** (no root export): - `@repo/ui/*` - - `@repo/error/*` - `@repo/email/*` - `@repo/notif/*` - **Mixed**: - `@repo/utils` has a root barrel **and** subpath exports. Prefer subpaths for clarity and smaller import surfaces. + - `@repo/error` has a root barrel for utilities (`getErrorMessage`, `tryCatch`) **and** platform-specific subpath exports (`/node`, `/nextjs`, `/browser`, `/react`).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docu/content/docs/development/packages.mdx` around lines 19 - 25, The docs incorrectly classify `@repo/error` as "Subpath-only" while later examples show root imports like getErrorMessage and tryCatch; update the package listing to either move `@repo/error/`* out of the "Subpath-only packages" block and into the "Mixed" category alongside `@repo/utils`, or add a clarifying sentence under `@repo/error` stating that root exports (e.g., getErrorMessage, tryCatch) exist for utility functions while platform-specific modules still require subpath imports; update the section that currently lists `@repo/error/`* and the later mentions of getErrorMessage and tryCatch to reflect the chosen approach.
🧹 Nitpick comments (2)
packages/error/src/core/capture-impl.ts (1)
80-86: Consider defensive handling if logger itself throws.The catch block logs errors when
captureExceptionfails, but iflog.erroritself throws (e.g., due to a misconfigured logger), it would result in an unhandled promise rejection. This is a minor edge case since loggers rarely throw.🔧 Optional: Defensive try-catch in error handler
.catch(err => { const log = options.logger ?? defaultLogger - log.error( - { err, label: options.label, code: options.code, ...options.data }, - 'Error reporting failed (captureException threw)', - ) + try { + log.error( + { err, label: options.label, code: options.code, ...options.data }, + 'Error reporting failed (captureException threw)', + ) + } catch { + // Silently swallow - nothing more we can do + } })🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/error/src/core/capture-impl.ts` around lines 80 - 86, The catch handler in captureException (the .catch block that gets the logger via options.logger ?? defaultLogger and calls log.error) should defensively handle the case where log.error itself throws: wrap the log.error invocation in a try/catch and, if it throws, fall back to a safe notifier such as console.error (including both the original err and the logger error) so the rejection is not propagated; ensure you still include options.label, options.code and options.data in the fallback message.apps/docu/content/docs/architecture/error-handling.mdx (1)
49-55: Consider clarifying the section heading.The heading "Initialize Sentry" at line 49 followed by "Sentry is not initialized by
@repo/error" at line 51 may be slightly confusing. Consider renaming the heading to something like "Error Reporting Initialization" or "Sentry Setup (External)" to better convey that initialization is handled outside@repo/error.📝 Suggested heading change
-### Initialize Sentry +### Error Reporting Initialization (External) -Sentry is not initialized by `@repo/error`. Follow your platform's setup: +`@repo/error` does not initialize Sentry internally. Follow your platform's setup:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docu/content/docs/architecture/error-handling.mdx` around lines 49 - 55, Rename the "Initialize Sentry" section to a clearer heading that signals initialization is external to the package (e.g., "Error Reporting Initialization" or "Sentry Setup (External)") and update any surrounding text to match; specifically change the heading string "Initialize Sentry" and ensure the explanatory sentence mentioning `@repo/error` ("Sentry is not initialized by `@repo/error`") remains directly underneath so readers understand initialization is handled outside the package.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.cursor/skills/next-v16/error-handling.md:
- Line 3: Update the wording to remove the ambiguous "Sentry reporting" phrase
and explicitly reference the package import paths: state that error handling
uses the `@repo/error` package (Sentry-backed) and structured logging via
`@repo/utils/logger/server` or `@repo/utils/logger/client`; e.g., replace "Sentry
reporting" with "the `@repo/error` package (Sentry-backed)" so the doc
consistently reflects the actual imports and abstraction level.
In `@apps/next/app/global-error.tsx`:
- Line 27: The logger.error call in the root layout should not include the raw
browser Error object; update the code that currently calls logger.error({
digest: error.digest, error }, 'Unhandled error in root layout') so it only logs
sanitized metadata (e.g., digest and a safe, redacted message string or flags)
and remove error or stack from the payload; keep the captureError(error) call
for full reporting, and if available use the logger's redaction feature (or a
helper like redactErrorInfo) to ensure no tokens/query params are emitted while
still including context for debugging.
In `@apps/next/error-reporting.client.ts`:
- Around line 4-6: The client initErrorReporting call currently uses
env.NEXT_PUBLIC_NODE_ENV which diverges from the server's
ERROR_REPORTING_ENVIRONMENT ?? NODE_ENV logic; update the environment argument
to use the public override if present by changing environment to
env.NEXT_PUBLIC_ERROR_REPORTING_ENVIRONMENT ?? env.NEXT_PUBLIC_NODE_ENV (keep
dsn: env.NEXT_PUBLIC_ERROR_REPORTING_DSN intact) so client and server share the
same environment tag, referencing initErrorReporting and the env.* variables.
In `@packages/error/src/react/error-boundary.tsx`:
- Around line 11-12: Update the documentation/comment on the captureError
property in AppErrorBoundary to remove any mention of "@repo/error/node"
(AppErrorBoundary is a 'use client' component), and instead only reference
"@repo/error/browser" and "@repo/error/nextjs"; ensure the comment near
captureError:(options: CaptureErrorOptions)=>void and any exported JSDoc or
inline text in error-boundary.tsx no longer suggests importing server-only
modules like `@repo/error/node` so client bundles won't pull pino or server-only
envs.
In `@packages/error/src/types.ts`:
- Line 1: The import in types.ts references a server-specific path for the
Logger type; change the type-only import to a neutral/shared logger type export
(e.g., import Logger from '@repo/utils/logger/types' or from
'@repo/utils/logger' if it exposes a platform-neutral export) so the shared
types file doesn't imply server-only usage—update the import statement that
currently references Logger from '@repo/utils/logger/server' to the shared
Logger export and ensure the import remains type-only.
---
Outside diff comments:
In @.cursor/skills/wagmi-v3/SKILL.md:
- Around line 570-576: Comment is stale: change the "Log to Sentry" comment
above the captureError call to reference the new error package instead of
Sentry. Update the comment to something like "Report error via
`@repo/error/nextjs`" (or simply "Report error") so it matches the use of
captureError from `@repo/error/nextjs`; keep the captureError({ code:
'TRANSACTION_ERROR', error, label: 'Contract Write', data: { request } }) call
unchanged.
In `@apps/docu/content/docs/development/packages.mdx`:
- Around line 19-25: The docs incorrectly classify `@repo/error` as "Subpath-only"
while later examples show root imports like getErrorMessage and tryCatch; update
the package listing to either move `@repo/error/`* out of the "Subpath-only
packages" block and into the "Mixed" category alongside `@repo/utils`, or add a
clarifying sentence under `@repo/error` stating that root exports (e.g.,
getErrorMessage, tryCatch) exist for utility functions while platform-specific
modules still require subpath imports; update the section that currently lists
`@repo/error/`* and the later mentions of getErrorMessage and tryCatch to reflect
the chosen approach.
In `@apps/fastify/src/plugins/error-handler.ts`:
- Around line 79-86: Update the stale comments that mention "Sentry" to
reference the generic error reporting abstraction (imported from
`@repo/error/node`) for consistency; specifically change the comment above the
sanitization lines near the calls to redactHeaders and redactBody and the
comment before the reporting call (around mapHttpStatusToErrorCode usage) to
mention the generic error reporter or error-reporting abstraction instead of
"Sentry", ensuring the comments align with the imported module and the functions
redactHeaders, redactBody, and mapHttpStatusToErrorCode.
In `@README.md`:
- Line 57: The README's dev command description still references the old package
name "sentry"; update the string in the dev command entry (the line showing the
`dev` command description that currently reads "`dev` — Start dev (core, react,
sentry, utils, fastify, next)") to replace "sentry" with "error" so it reads
"`dev` — Start dev (core, react, error, utils, fastify, next)"; ensure any other
occurrences of "sentry" in README command lists are similarly updated for
consistency.
---
Nitpick comments:
In `@apps/docu/content/docs/architecture/error-handling.mdx`:
- Around line 49-55: Rename the "Initialize Sentry" section to a clearer heading
that signals initialization is external to the package (e.g., "Error Reporting
Initialization" or "Sentry Setup (External)") and update any surrounding text to
match; specifically change the heading string "Initialize Sentry" and ensure the
explanatory sentence mentioning `@repo/error` ("Sentry is not initialized by
`@repo/error`") remains directly underneath so readers understand initialization
is handled outside the package.
In `@packages/error/src/core/capture-impl.ts`:
- Around line 80-86: The catch handler in captureException (the .catch block
that gets the logger via options.logger ?? defaultLogger and calls log.error)
should defensively handle the case where log.error itself throws: wrap the
log.error invocation in a try/catch and, if it throws, fall back to a safe
notifier such as console.error (including both the original err and the logger
error) so the rejection is not propagated; ensure you still include
options.label, options.code and options.data in the fallback message.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d31c5be0-1a97-4ca7-8f70-7039552a6d68
⛔ Files ignored due to path filters (2)
packages/error/tsconfig.jsonis excluded by!**/tsconfig*.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!**/pnpm-lock.yaml
📒 Files selected for processing (66)
.cursor/skills/next-v16/error-handling.md.cursor/skills/wagmi-v3/SKILL.mdREADME.mdapps/docu/content/docs/architecture/error-handling.mdxapps/docu/content/docs/architecture/esm-strategy.mdxapps/docu/content/docs/architecture/logging.mdxapps/docu/content/docs/deployment/vercel.mdxapps/docu/content/docs/development/dev-tooling.mdxapps/docu/content/docs/development/package-conventions.mdxapps/docu/content/docs/development/packages.mdxapps/fastify/package.jsonapps/fastify/scripts/create-verification-table.tsapps/fastify/server.tsapps/fastify/src/lib/env.tsapps/fastify/src/plugins/auth.tsapps/fastify/src/plugins/error-handler.tsapps/fastify/src/routes/auth/session/refresh.tsapps/next/README.mdapps/next/app/(dashboard)/(news)/page.tsxapps/next/app/(dashboard)/markets/page.tsxapps/next/app/global-error.tsxapps/next/error-reporting.client.tsapps/next/error-reporting.server.tsapps/next/instrumentation-client.tsapps/next/instrumentation.tsapps/next/lib/env.tsapps/next/next.config.mjsapps/next/package.jsonapps/next/sentry.edge.config.tsapps/next/sentry.server.config.tsbiome.jsonpackages/error/README.mdpackages/error/eslint.config.mjspackages/error/package.jsonpackages/error/src/__tests__/browser.test.tspackages/error/src/__tests__/capture.test.tspackages/error/src/__tests__/sentry.test.tspackages/error/src/browser/capture.tspackages/error/src/browser/index.tspackages/error/src/browser/sentry.tspackages/error/src/core/capture-impl.tspackages/error/src/core/index.tspackages/error/src/nextjs/capture.tspackages/error/src/nextjs/index.tspackages/error/src/nextjs/sentry.tspackages/error/src/node/capture.tspackages/error/src/node/index.tspackages/error/src/node/sentry.tspackages/error/src/react/error-boundary.tsxpackages/error/src/react/index.tspackages/error/src/types.tspackages/error/src/utils/index.tspackages/error/src/utils/types.tspackages/error/tsup.config.tspackages/error/vitest.config.tspackages/react/README.mdpackages/sentry/README.mdpackages/sentry/src/core/capture-impl.tspackages/sentry/src/nextjs/index.tspackages/sentry/src/types.tspackages/utils/README.mdpackages/utils/package.jsonpackages/utils/src/error/README.mdpackages/utils/src/index.tspackages/utils/tsup.config.tsturbo.json
💤 Files with no reviewable changes (9)
- packages/utils/package.json
- packages/utils/src/index.ts
- packages/utils/tsup.config.ts
- packages/sentry/src/nextjs/index.ts
- packages/utils/README.md
- packages/sentry/src/types.ts
- packages/sentry/src/core/capture-impl.ts
- packages/sentry/README.md
- packages/utils/src/error/README.md
- next-v16: replace ambiguous 'Sentry reporting' with @repo/error package refs - global-error: log only sanitized metadata (digest), not raw error object - error-reporting.client: use NEXT_PUBLIC_ERROR_REPORTING_ENVIRONMENT ?? NODE_ENV - error-boundary: remove @repo/error/node from captureError JSDoc (client-only) - types: import Logger from @repo/utils/logger/types (platform-neutral) - wagmi skill: update 'Log to Sentry' comment to 'Report error via @repo/error/nextjs' - packages.mdx: move @repo/error to Mixed (root + subpath exports) - error-handler: replace Sentry comments with error-reporting abstraction refs - README: dev command sentry → error - error-handling.mdx: rename 'Initialize Sentry' to 'Error Reporting Initialization' - capture-impl: wrap log.error in try/catch, fallback to console on logger throw - utils: add @repo/utils/logger/types export
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
apps/docu/content/docs/architecture/error-handling.mdx (4)
10-12: ClarifygetErrorMessageavailability per platform.Line 11 states
getErrorMessageis available from "base export or@repo/error/nextjs." However, the@repo/error/nodeentry point does not re-exportgetErrorMessage(onlycaptureErrorandinitErrorReporting), while@repo/error/nextjsexplicitly re-exports it from the utils module.Consider noting this distinction so Node.js users know to import from
@repo/error(base) rather than@repo/error/nodeforgetErrorMessage.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docu/content/docs/architecture/error-handling.mdx` around lines 10 - 12, Clarify that getErrorMessage is exported from the package root (use import from `@repo/error` or `@repo/error/nextjs`) but is NOT re-exported by the platform-specific node entrypoint; update the text around getErrorMessage, captureError, and initErrorReporting to state that captureError and initErrorReporting are available from `@repo/error/node` while getErrorMessage must be imported from the base export (`@repo/error`) or from `@repo/error/nextjs` where it is re-exported, so Node.js users should not rely on `@repo/error/node` to access getErrorMessage.
312-313: Same as above: combine imports.-import { getErrorMessage } from '@repo/error/nextjs' -import { captureError } from '@repo/error/nextjs' +import { captureError, getErrorMessage } from '@repo/error/nextjs'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docu/content/docs/architecture/error-handling.mdx` around lines 312 - 313, Combine the two separate import statements into a single import that imports both getErrorMessage and captureError from the same module; update the import line that currently references getErrorMessage and captureError separately to a single destructured import from '@repo/error/nextjs' so both symbols are imported together.
178-179: Consider combining imports from the same module.These two imports are from the same
@repo/error/nextjsmodule and could be combined into a single statement for clarity.📝 Suggested fix
-import { captureError } from '@repo/error/nextjs' -import { getErrorMessage } from '@repo/error/nextjs' +import { captureError, getErrorMessage } from '@repo/error/nextjs'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docu/content/docs/architecture/error-handling.mdx` around lines 178 - 179, Combine the two separate imports from the same module into a single import statement: replace the separate import lines that import captureError and getErrorMessage from '@repo/error/nextjs' with one consolidated import that imports both symbols (captureError, getErrorMessage) from '@repo/error/nextjs'.
49-56: Clarify relationship betweeninitErrorReportingand Sentry setup.Line 12 directs users to use
initErrorReportingfrom@repo/error/nodeor@repo/error/nextjs, but line 51 states "Sentry is not initialized by@repo/error." This appears contradictory.Consider clarifying whether
initErrorReportingwraps Sentry initialization or if it's a separate step that assumes Sentry is already configured via the platform-specific guides.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/docu/content/docs/architecture/error-handling.mdx` around lines 49 - 56, The docs are ambiguous about initErrorReporting vs Sentry initialization; update the text so it explicitly states the contract of initErrorReporting from `@repo/error/node` and `@repo/error/nextjs`: either (A) it internally calls Sentry.init and configures integrations/handlers (describe that behavior briefly), or (B) it assumes the caller has already called Sentry.init per the platform guides and initErrorReporting only wires in project-specific handlers (describe that behavior briefly). Modify the paragraph that currently says "Sentry is not initialized by `@repo/error`" to match the actual implementation of the initErrorReporting function (referencing initErrorReporting, `@repo/error/node`, `@repo/error/nextjs`) and add one example sentence showing whether users must call Sentry.init themselves or not.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/error/src/react/error-boundary.tsx`:
- Around line 24-27: Update the top doc comment for the ErrorBoundary component
to reflect that it is a client-only component (it has 'use client') and remove
any mention of Node.js or server-side packages like `@repo/error/node`; instead
state it supports client-side error reporting implementations such as Next.js
(client) and browser error reporting. Make this change in the comment for the
ErrorBoundary class/component in error-boundary.tsx so the documentation
accurately matches the component's client-only constraints.
---
Nitpick comments:
In `@apps/docu/content/docs/architecture/error-handling.mdx`:
- Around line 10-12: Clarify that getErrorMessage is exported from the package
root (use import from `@repo/error` or `@repo/error/nextjs`) but is NOT re-exported
by the platform-specific node entrypoint; update the text around
getErrorMessage, captureError, and initErrorReporting to state that captureError
and initErrorReporting are available from `@repo/error/node` while getErrorMessage
must be imported from the base export (`@repo/error`) or from `@repo/error/nextjs`
where it is re-exported, so Node.js users should not rely on `@repo/error/node` to
access getErrorMessage.
- Around line 312-313: Combine the two separate import statements into a single
import that imports both getErrorMessage and captureError from the same module;
update the import line that currently references getErrorMessage and
captureError separately to a single destructured import from
'@repo/error/nextjs' so both symbols are imported together.
- Around line 178-179: Combine the two separate imports from the same module
into a single import statement: replace the separate import lines that import
captureError and getErrorMessage from '@repo/error/nextjs' with one consolidated
import that imports both symbols (captureError, getErrorMessage) from
'@repo/error/nextjs'.
- Around line 49-56: The docs are ambiguous about initErrorReporting vs Sentry
initialization; update the text so it explicitly states the contract of
initErrorReporting from `@repo/error/node` and `@repo/error/nextjs`: either (A) it
internally calls Sentry.init and configures integrations/handlers (describe that
behavior briefly), or (B) it assumes the caller has already called Sentry.init
per the platform guides and initErrorReporting only wires in project-specific
handlers (describe that behavior briefly). Modify the paragraph that currently
says "Sentry is not initialized by `@repo/error`" to match the actual
implementation of the initErrorReporting function (referencing
initErrorReporting, `@repo/error/node`, `@repo/error/nextjs`) and add one example
sentence showing whether users must call Sentry.init themselves or not.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 31c2c727-ecaf-492d-b503-d616082309e7
📒 Files selected for processing (13)
.cursor/skills/next-v16/error-handling.md.cursor/skills/wagmi-v3/SKILL.mdREADME.mdapps/docu/content/docs/architecture/error-handling.mdxapps/docu/content/docs/development/packages.mdxapps/fastify/src/plugins/error-handler.tsapps/next/app/global-error.tsxapps/next/error-reporting.client.tspackages/error/src/core/capture-impl.tspackages/error/src/react/error-boundary.tsxpackages/error/src/types.tspackages/utils/package.jsonpackages/utils/tsup.config.ts
🚧 Files skipped from review as they are similar to previous changes (6)
- packages/error/src/core/capture-impl.ts
- packages/utils/tsup.config.ts
- apps/next/error-reporting.client.ts
- packages/utils/package.json
- apps/docu/content/docs/development/packages.mdx
- .cursor/skills/next-v16/error-handling.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit