next.js

ac86a613 - Refactor extractExportedConstValue to return { value } | null instead of throwing (#90510)

Refactor extractExportedConstValue to return { value } | null instead of throwing (#90510) ## Summary Refactors `extractExportedConstValue` and the internal `extractValue` function to use return values instead of exception-based control flow, improving performance during build analysis. ### Commit 1: Refactor `extractExportedConstValue` - Returns `{ value: any } | null` instead of throwing `NoSuchDeclarationError` - `null` when the exported const declaration is not found, `{ value }` when found - Removes `NoSuchDeclarationError` class ### Commit 2: Refactor `extractValue` - Returns `ExtractValueResult` (`{ value: any } | { unsupported: string; path?: string }`) instead of throwing `UnsupportedValueError` - Extracts path-formatting logic from `UnsupportedValueError` constructor into a standalone `formatCodePath` helper - All 6 throw sites become return statements; 3 recursive call sites propagate unsupported results - Removes `UnsupportedValueError` class entirely - Removes all try/catch blocks from the 4 callsites in `get-page-static-info.ts` - Updates `warnAboutUnsupportedValue` to accept the result type directly ## Motivation Both `extractExportedConstValue` and `extractValue` used throw/catch for expected control flow — a missing declaration and unsupported AST node types are normal cases during build analysis, not exceptional errors. Every page/route processed during build hits these functions multiple times. Constructing `Error` objects (which capture stack traces) and unwinding the stack is expensive in V8. Returning discriminated result types avoids this overhead entirely. ## Test Plan - Existing unit tests pass (`test/unit/parse-page-static-info.test.ts` — 5/5) - No behavioral change: callsites produce identical warnings/errors for unsupported values and silently skip missing declarations, same as before