fix(build): keep console.error in production builds - #370
Merged
Conversation
`removeConsole: true` strips every console method from application code, including the `console.error` that `withErrorHandler` relies on to emit its structured error payload. Production server errors were therefore silent, and a domain 404 raised by a use case was indistinguishable from a Next routing 404 in the platform logs. Excluding `error` restores that signal while still dropping `log`/`warn`/`debug` noise.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
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.
What
removeConsole: truestrips every console method from application code in production builds, including theconsole.errorthatwithErrorHandlerrelies on to emit its structured error payload. Production server errors were therefore silent, and a domain 404 raised by a use case was indistinguishable from a Next routing 404 in the platform logs.Excluding
errorrestores that signal while still droppinglog/warn/debugnoise.Why now
This is the direct reason the rally-404 bug (ATE-92) went misdiagnosed for two weeks — the structured error payload existed but never reached the platform logs. It is also a prerequisite for any error tracking work: an error reporter wired up on top of a build that strips
console.errorstill receives nothing.Scope notes
next.config.js. No application code, no behavior change for users..claude/skills/writing-changesets.ate-92prefix because the commit was authored during that investigation; the tracked issue is ATE-103.Verification
pnpm verify:allpasses locally (format, workflow checks, strict typecheck, lint, tests,pnpm build, service-worker assertion, blueprint build).Refs ATE-103
摘要(zh-TW)
removeConsole: true會在 production build 移除所有 console 方法,連withErrorHandler用來輸出結構化錯誤內容的console.error也一併被移除,導致線上伺服器錯誤完全靜默,use case 拋出的領域 404 在平台日誌中與 Next 路由 404 無法區分。改為排除error後恢復此訊號,同時仍濾掉log/warn/debug噪音。這正是 ATE-92(rally 送出一律 404)被誤診兩週的直接原因,也是後續接上錯誤追蹤的前提——在會 strip
console.error的 build 上接錯誤回報器仍然收不到任何東西。僅動
next.config.js一行,無使用者可見的行為變更,因此依 changeset 規範豁免不附 changeset;同理無 Blueprint Change 可歸檔(即 ATE-109 追蹤的輕量路徑缺口)。本地pnpm verify:all全綠。