@vercel/error

Use structured fields to identify what failed, explain why, and suggest what to do next. Software should branch on stable fields; people and agents should read the prose. Preserve the fields until output is rendered, and never parse terminal formatting.

Workflow

1. Inspect the target project

Read the target project's package.json, lockfile, existing errors, output paths, logging, and tests before choosing an API.

• Use the installed @vercel/error version's public exports as the contract. Do not deep-import unexported source paths.
• If the package is absent, resolve the intended version from workspace constraints or the current release, then inspect its published exports and engines. Add it as a production dependency only for requested implementation work.
• Compare a Node target's version with the selected version's engines, and report an incompatibility instead of silently changing the runtime. The package itself is isomorphic (browsers, workers, edge runtimes), so treat engines as the Node support matrix, not a runtime allowlist.
• Record the project's existing code and scope names and the callers that depend on them. In step 4, preserve or challenge those conventions based on evidence.
• Leave dependencies unchanged for advice and review.

Before continuing, record the selected version and runtime compatibility, verify the public imports, and identify where the error is created, handled, sent, logged, or shown.

2. Decide whether a structured error is needed