next.js

f68f70b0 - Recognize `super(...)` messages in Error subclass constructors (#93182)

Recognize `super(...)` messages in Error subclass constructors (#93182) The error-code SWC plugin at `crates/next-error-code-swc-plugin` previously only transformed `new Error(msg)` call sites where the constructor identifier was in the hard-coded `is_error_class_name` list. Subclasses not in that list — for example `UseCacheTimeoutError`, which defines its message inside the constructor via `super('...')` and is instantiated with no arguments — went undetected, so their instances carried no `__NEXT_ERROR_CODE` at all. The plugin now also visits class declarations and expressions. When it sees `class X extends Y` where `Y` is one of the recognized Error classes, it finds the first top-level `super(arg)` call inside the constructor body, resolves the argument to a string via the existing `stringify_new_error_arg` logic (which handles string literals, template literals, string concatenations, and resolved identifier bindings), and inserts an `Object.defineProperty(this, '__NEXT_ERROR_CODE', ...)` statement immediately after the `super` call. Messages that aren't in `errors.json` yet are emitted to `cwd/.errors/<hash>.json` and consolidated by the existing `check-error-codes` build step, exactly as the call-site path already does. Classes whose `super` is nested inside an `if` or `try`, or whose only argument is a spread (`super(...args)`), are left alone. Classes that are already in `is_error_class_name` (for example `InvariantError`) now get a code assigned at both their call sites and inside their constructor body. The call-site `Object.defineProperty` runs after the constructor and therefore takes precedence at runtime, so observable behavior at those sites is unchanged. The constructor injection is defensive for any future instantiation that the call-site pass doesn't cover. `packages/next/errors.json` gains nine entries for super messages in existing Error subclasses that the plugin now captures for the first time.