Test Actions v2#1
Closed
ijjk wants to merge 0 commit into
Closed
Conversation
Owner
Author
Stats from current PRDefault Server Mode (Increase detected
|
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| buildDuration | 23.4s | 23.2s | -148ms |
| nodeModulesSize | 42.4 MB | 42.4 MB |
Client Bundles (main, webpack, commons)
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| main-HASH.js | 18.3 kB | 18.3 kB | ✓ |
| main-HASH.js gzip | 6.65 kB | 6.65 kB | ✓ |
| webpack-HASH.js | 1.53 kB | 1.53 kB | ✓ |
| webpack-HASH.js gzip | 746 B | 746 B | ✓ |
| 4952ddcd88e7..2b8407376.js | 21.9 kB | 21.9 kB | ✓ |
| 4952ddcd88e7..7376.js gzip | 7.81 kB | 7.81 kB | ✓ |
| de003c3a9d30..799a4e38e.js | 43.1 kB | 43.1 kB | ✓ |
| de003c3a9d30..e38e.js gzip | 15.4 kB | 15.4 kB | ✓ |
| framework.5b..dbaff70d3.js | 125 kB | 125 kB | ✓ |
| framework.5b..70d3.js gzip | 39.4 kB | 39.4 kB | ✓ |
| Overall change | 210 kB | 210 kB | ✓ |
Client Bundles (main, webpack, commons) Modern
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| main-HASH.module.js | 16.6 kB | 16.6 kB | ✓ |
| main-HASH.module.js gzip | 6.4 kB | 6.4 kB | ✓ |
| webpack-HASH.module.js | 1.53 kB | 1.53 kB | ✓ |
| webpack-HASH..dule.js gzip | 746 B | 746 B | ✓ |
| de003c3a9d30..f0.module.js | 45.5 kB | 45.5 kB | ✓ |
| de003c3a9d30..dule.js gzip | 16.5 kB | 16.5 kB | ✓ |
| framework.5b..d3.module.js | 125 kB | 125 kB | ✓ |
| framework.5b..dule.js gzip | 39.4 kB | 39.4 kB | ✓ |
| Overall change | 189 kB | 189 kB | ✓ |
Client Pages
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _app.js | 1.83 kB | 1.83 kB | ✓ |
| _app.js gzip | 883 B | 883 B | ✓ |
| _error.js | 12.1 kB | 12.1 kB | ✓ |
| _error.js gzip | 4.74 kB | 4.74 kB | ✓ |
| hooks.js | 12.7 kB | 12.7 kB | ✓ |
| hooks.js gzip | 4.81 kB | 4.81 kB | ✓ |
| index.js | 343 B | 343 B | ✓ |
| index.js gzip | 237 B | 237 B | ✓ |
| link.js | 8.14 kB | 8.14 kB | ✓ |
| link.js gzip | 3.49 kB | 3.49 kB | ✓ |
| routerDirect.js | 433 B | 433 B | ✓ |
| routerDirect.js gzip | 296 B | 296 B | ✓ |
| withRouter.js | 444 B | 444 B | ✓ |
| withRouter.js gzip | 294 B | 294 B | ✓ |
| Overall change | 36 kB | 36 kB | ✓ |
Client Pages Modern
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _app.module.js | 1.73 kB | 1.73 kB | ✓ |
| _app.module.js gzip | 841 B | 841 B | ✓ |
| _error.module.js | 23.3 kB | 23.3 kB | ✓ |
| _error.module.js gzip | 8.6 kB | 8.6 kB | ✓ |
| hooks.module.js | 1.55 kB | 1.55 kB | ✓ |
| hooks.module.js gzip | 804 B | 804 B | ✓ |
| index.module.js | 319 B | 319 B | ✓ |
| index.module.js gzip | 238 B | 238 B | ✓ |
| link.module.js | 8.52 kB | 8.52 kB | ✓ |
| link.module.js gzip | 3.67 kB | 3.67 kB | ✓ |
| routerDirect.module.js | 419 B | 419 B | ✓ |
| routerDirect..dule.js gzip | 294 B | 294 B | ✓ |
| withRouter.module.js | 429 B | 429 B | ✓ |
| withRouter.m..dule.js gzip | 293 B | 293 B | ✓ |
| Overall change | 36.2 kB | 36.2 kB | ✓ |
Client Build Manifests
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _buildManifest.js | 81 B | 81 B | ✓ |
| _buildManifest.js gzip | 61 B | 61 B | ✓ |
| _buildManifest.module.js | 81 B | 81 B | ✓ |
| _buildManife..dule.js gzip | 61 B | 61 B | ✓ |
| Overall change | 162 B | 162 B | ✓ |
Rendered Page Sizes
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| index.html | 3.62 kB | 3.62 kB | ✓ |
| index.html gzip | 947 B | 947 B | ✓ |
| link.html | 3.66 kB | 3.66 kB | ✓ |
| link.html gzip | 956 B | 956 B | ✓ |
| withRouter.html | 3.67 kB | 3.67 kB | ✓ |
| withRouter.html gzip | 943 B | 943 B | ✓ |
| Overall change | 10.9 kB | 10.9 kB | ✓ |
Serverless Mode (Increase detected ⚠️ )
General Overall increase ⚠️
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| buildDuration | 23.4s | 23.1s | -338ms |
| nodeModulesSize | 42.4 MB | 42.4 MB |
Client Bundles (main, webpack, commons)
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| main-HASH.js | 18.3 kB | 18.3 kB | ✓ |
| main-HASH.js gzip | 6.65 kB | 6.65 kB | ✓ |
| webpack-HASH.js | 1.53 kB | 1.53 kB | ✓ |
| webpack-HASH.js gzip | 746 B | 746 B | ✓ |
| 4952ddcd88e7..2b8407376.js | 21.9 kB | 21.9 kB | ✓ |
| 4952ddcd88e7..7376.js gzip | 7.81 kB | 7.81 kB | ✓ |
| de003c3a9d30..799a4e38e.js | 43.1 kB | 43.1 kB | ✓ |
| de003c3a9d30..e38e.js gzip | 15.4 kB | 15.4 kB | ✓ |
| framework.5b..dbaff70d3.js | 125 kB | 125 kB | ✓ |
| framework.5b..70d3.js gzip | 39.4 kB | 39.4 kB | ✓ |
| Overall change | 210 kB | 210 kB | ✓ |
Client Bundles (main, webpack, commons) Modern
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| main-HASH.module.js | 16.6 kB | 16.6 kB | ✓ |
| main-HASH.module.js gzip | 6.4 kB | 6.4 kB | ✓ |
| webpack-HASH.module.js | 1.53 kB | 1.53 kB | ✓ |
| webpack-HASH..dule.js gzip | 746 B | 746 B | ✓ |
| de003c3a9d30..f0.module.js | 45.5 kB | 45.5 kB | ✓ |
| de003c3a9d30..dule.js gzip | 16.5 kB | 16.5 kB | ✓ |
| framework.5b..d3.module.js | 125 kB | 125 kB | ✓ |
| framework.5b..dule.js gzip | 39.4 kB | 39.4 kB | ✓ |
| Overall change | 189 kB | 189 kB | ✓ |
Client Pages
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _app.js | 1.83 kB | 1.83 kB | ✓ |
| _app.js gzip | 883 B | 883 B | ✓ |
| _error.js | 12.1 kB | 12.1 kB | ✓ |
| _error.js gzip | 4.74 kB | 4.74 kB | ✓ |
| hooks.js | 12.7 kB | 12.7 kB | ✓ |
| hooks.js gzip | 4.81 kB | 4.81 kB | ✓ |
| index.js | 343 B | 343 B | ✓ |
| index.js gzip | 237 B | 237 B | ✓ |
| link.js | 8.14 kB | 8.14 kB | ✓ |
| link.js gzip | 3.49 kB | 3.49 kB | ✓ |
| routerDirect.js | 433 B | 433 B | ✓ |
| routerDirect.js gzip | 296 B | 296 B | ✓ |
| withRouter.js | 444 B | 444 B | ✓ |
| withRouter.js gzip | 294 B | 294 B | ✓ |
| Overall change | 36 kB | 36 kB | ✓ |
Client Pages Modern
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _app.module.js | 1.73 kB | 1.73 kB | ✓ |
| _app.module.js gzip | 841 B | 841 B | ✓ |
| _error.module.js | 23.3 kB | 23.3 kB | ✓ |
| _error.module.js gzip | 8.6 kB | 8.6 kB | ✓ |
| hooks.module.js | 1.55 kB | 1.55 kB | ✓ |
| hooks.module.js gzip | 804 B | 804 B | ✓ |
| index.module.js | 319 B | 319 B | ✓ |
| index.module.js gzip | 238 B | 238 B | ✓ |
| link.module.js | 8.52 kB | 8.52 kB | ✓ |
| link.module.js gzip | 3.67 kB | 3.67 kB | ✓ |
| routerDirect.module.js | 419 B | 419 B | ✓ |
| routerDirect..dule.js gzip | 294 B | 294 B | ✓ |
| withRouter.module.js | 429 B | 429 B | ✓ |
| withRouter.m..dule.js gzip | 293 B | 293 B | ✓ |
| Overall change | 36.2 kB | 36.2 kB | ✓ |
Client Build Manifests
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _buildManifest.js | 81 B | 81 B | ✓ |
| _buildManifest.js gzip | 61 B | 61 B | ✓ |
| _buildManifest.module.js | 81 B | 81 B | ✓ |
| _buildManife..dule.js gzip | 61 B | 61 B | ✓ |
| Overall change | 162 B | 162 B | ✓ |
Serverless bundles
| zeit/next.js canary | ijjk/next.js fix/public-dynamic-priority | Change | |
|---|---|---|---|
| _error.js | 247 kB | 247 kB | ✓ |
| _error.js gzip | 66.1 kB | 66.1 kB | ✓ |
| hooks.html | 3.73 kB | 3.73 kB | ✓ |
| hooks.html gzip | 973 B | 973 B | ✓ |
| index.js | 248 kB | 248 kB | ✓ |
| index.js gzip | 66.5 kB | 66.5 kB | ✓ |
| link.js | 255 kB | 255 kB | ✓ |
| link.js gzip | 68.5 kB | 68.5 kB | ✓ |
| routerDirect.js | 249 kB | 249 kB | ✓ |
| routerDirect.js gzip | 66.5 kB | 66.5 kB | ✓ |
| withRouter.js | 248 kB | 248 kB | ✓ |
| withRouter.js gzip | 66.6 kB | 66.6 kB | ✓ |
| Overall change | 1.25 MB | 1.25 MB | ✓ |
ijjk
pushed a commit
that referenced
this pull request
Oct 25, 2022
Enables `appDir` test for `deploy` in the `test/e2e/app-dir/index.test.ts` test suite.
ijjk
pushed a commit
that referenced
this pull request
Aug 15, 2024
…etPrefix (vercel#68694) This PR fixes two issues with the use of `assetPrefix`: #1: vercel#64710 `assetPrefix` needs to be handled in `dev`, `deploy`, and `start`. In the current approach, only `dev` and `start` were handled, but a quirk of the implementation caused rewrites for non-asset paths to not be able to be used in `afterFiles` rewrites. #2: When deploying Next.js (such as on Vercel), you need to add your own `beforeFiles` rewrite for `/${assetPrefix}/_next/...` requests or otherwise they would 404. This PR creates an automatically added `rewrite` to `beforeFiles` that handles the case for `dev`, `start`, and `deploy`, removes the existing logic in `filesystem.ts`, and adds more tests to check the behavior.
ijjk
pushed a commit
that referenced
this pull request
Jan 8, 2026
## Move "Ready in X" log before config loading and eliminate duplicate `loadConfig` calls ### What? Reorder the dev server startup flow so the "Ready in X" log appears before loading the user's `next.config.js`, and eliminate duplicate `loadConfig` calls in both dev and build paths. ### Why? Previously, the "Ready in X" time included the time spent loading and evaluating the user's `next.config.js` file. This made the framework appear slower than it actually is, especially for projects with complex config files or slow config evaluation. Additionally, config was being loaded twice: - **Dev server**: Once in `getStartServerInfo()` just for logging, then again in `getRequestHandlers()` - **Build**: Once for the main build, then again in `getStartServerInfo()` just for logging ### How? **Before:** ``` 1. getStartServerInfo() → loadConfig #1 (slow - blocks on next.config.js) 2. logStartInfo() → logs version, URLs, experimental features 3. "Ready in X" ← time includes config loading 4. getRequestHandlers() → loadConfig #2 ``` **After:** ``` 1. logStartInfo() → logs version, URLs, envInfo (no config needed) 2. "Ready in X" ← reflects actual framework startup time 3. getRequestHandlers() → loadConfig (once) 4. logExperimentalInfo() → logs experimental features ``` **Changes:** - Split `logStartInfo` into two functions: - `logStartInfo()` - basic info (version, URLs, env) - no config needed - `logExperimentalInfo()` - experimental features and cacheComponents - Removed `getStartServerInfo()` which was loading config unnecessarily - Added `experimentalFeatures` and `cacheComponents` to `ServerInitResult` so they can be passed back after config loads - In build, added `reportExperimentalFeatures` callback to the existing `loadConfig` call instead of loading config twice --------- Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
ijjk
pushed a commit
that referenced
this pull request
Apr 27, 2026
…leLog (vercel#92329) ## Background: three sources of file log entries Browser `console.*` calls in Next.js dev mode are forwarded to the server over a WebSocket. Before this PR, three independent mechanisms wrote to the `.next/logs/next-development.log` file: 1. **`ClientFileLogger`** (client → `client-file-logs` WS event → `handleClientFileLogs`) — a class in `forward-logs.ts` that intercepted every `console.*` call unconditionally, serialized args into message-only strings (no stack traces, no source mapping), and sent them to the server over a separate `client-file-logs` WebSocket event. The server's `handleClientFileLogs` wrote them directly to the file logger as `Browser` entries. 2. **`handleLog` direct file writes** (client → `browser-logs` WS event → `handleLog` → `fileLogger`) — the primary path. The browser's patched console methods serialize args into `ClientLogEntry` objects, batch them, and send them as `browser-logs` WebSocket events. On the server, `handleLog` in `receive-logs.ts` deserializes the args, source-maps stack traces, and forwards to the terminal. As a side effect, it also wrote directly to the file logger. 3. **`console-file.tsx` interception** (server-side `console.*` → `fileLogger.logServer`) — a server-side environment extension that patches the server process's own `console.*` methods. When `handleLog` calls `forwardConsole.error()` to print browser logs to the terminal, this interception captures that output and writes it as a `Server` entry. The `[browser]` text visible in these entries' messages is the terminal prefix leaking into the file log. ## Problems with the old system ### Duplicate entries On the client side, `createLogEntry` gated the `browser-logs` send behind `isTerminalLoggingEnabled`: ```javascript if (!isTerminalLoggingEnabled) { return // skip browser-logs WebSocket send } ``` But `clientFileLogger.log()` was called **before** this check, unconditionally. So `ClientFileLogger` always produced file log entries regardless of config. Meanwhile, `handleLog` was gated by `browserToTerminalConfig` in both hot reloaders. Because `experimental.browserDebugInfoInTerminal` defaults to `'warn'`, this gate was open by default — `handleLog` ran for errors and warnings even in code without explicit `logging.browserToTerminal` config, like this test. But `console.log` was filtered out at the `'warn'` level, so only `ClientFileLogger` wrote those. The net effect: errors and warnings were written to the file by **both** `ClientFileLogger` (message-only) and `handleLog` (with source-mapped stacks), producing duplicates. `console.log` was written only by `ClientFileLogger`. ### Mislabeled source The direct file writes inside `handleLog` had a bug: the `any-logged-error` and `formatted-error` code paths hardcoded `fileLogger.logBrowser()` instead of checking `isServerLog`. The `console` kind already checked `isServerLog` correctly. This inconsistency meant that when a server-decorated error (one with the `Symbol.for('NextjsError')` property set by `decorateServerError`) was logged via `console.error(serverError)` in the browser, the `sourceType` would be legitimately set to `'server'`, but the file log entry would still be labeled `Browser`. This bug didn't manifest in this test because the test calls `console.error('string')` with no Error objects — `forwardErrorLog` never finds an Error to call `getErrorSource` on, so `sourceType` remains `undefined` and `isServerLog` is `false`. The hardcoded `logBrowser` happened to produce the correct label by coincidence. ### The result With the default config, a single `console.error('string')` in the browser produced **three** file log entries: 1. `Browser ERROR` (message-only) — from `ClientFileLogger` 2. `Browser ERROR` (with stack) — from `handleLog`'s direct file write (hardcoded `logBrowser`) 3. `Server ERROR` (with stack + `[browser]` prefix) — from `console-file.tsx` intercepting `handleLog`'s `forwardConsole.error()` terminal output ## What this PR does **Removes `ClientFileLogger` and the `client-file-logs` channel entirely.** File logging now happens via `handleLog`'s direct writes and `console-file.tsx` interception. **Decouples the client-side send from terminal logging.** The old `createLogEntry` gated the `browser-logs` send on `isTerminalLoggingEnabled`. The new code gates on `shouldForwardLogs`: ```javascript const shouldForwardLogs = isTerminalLoggingEnabled || !!process.env.__NEXT_MCP_SERVER ``` This is the key mechanism that makes consolidation possible — `browser-logs` events now fire when either terminal logging or the MCP server (which controls file logging) is enabled, so `handleLog` always receives the entries it needs. **Decouples server-side file logging from terminal output.** `handleLog` is no longer gated by `browserToTerminalConfig` at the hot-reloader level — it always runs. Inside `handleLog`, terminal output and file logging are controlled independently: `shouldShowEntry(entry, config)` gates terminal output, `fileLogger.isEnabled()` gates file writes. **Fixes the `isServerLog` labeling bug.** All entry kinds (`console`, `any-logged-error`, `formatted-error`) now check `isServerLog` and call `logServer()`/`logBrowser()` accordingly. ## Snapshot diff explanation ### Old snapshot (7 entries) ``` 1. Browser LOG — "Complex circular object: ..." ← ClientFileLogger 2. Browser ERROR — "message" ← ClientFileLogger (message-only) 3. Browser WARN — "message" ← ClientFileLogger (message-only) 4. Server ERROR — "[browser] message + stack + loc" ← console-file.tsx (intercepting forwardConsole.error) 5. Browser ERROR — "message + stack + loc" ← handleLog any-logged-error (hardcoded logBrowser) 6. Server WARN — "[browser] message + loc" ← console-file.tsx (intercepting forwardConsole.warn) 7. Browser WARN — "message" ← handleLog console kind (logBrowser, isServerLog=false) ``` ### New snapshot (5 entries) ``` 1. Browser LOG — "Complex circular object: ..." ← handleLog console kind (logBrowser) 2. Browser ERROR — "message + stack + loc" ← handleLog any-logged-error (logBrowser) 3. Server ERROR — "[browser] message + stack + loc" ← console-file.tsx (intercepting forwardConsole.error) 4. Browser WARN — "message" ← handleLog console kind (logBrowser) 5. Server WARN — "[browser] message + loc" ← console-file.tsx (intercepting forwardConsole.warn) ``` ### What changed With `ClientFileLogger` removed, each `console.*` call now produces one `Browser` entry from `handleLog` instead of two (ClientFileLogger message-only + handleLog with stack). Per call: - **`console.log`**: old `#1` (ClientFileLogger) → new `#1` (handleLog). Previously only `ClientFileLogger` wrote this — `handleLog` skipped it because `log` level was below the `'warn'` terminal threshold. Now `handleLog` writes file logs for all entry kinds before the `shouldShow` check. - **`console.error`**: old `#2` (ClientFileLogger duplicate) removed. Old `#5` (handleLog) → new `#2`, now with cleaner formatting. - **`console.warn`**: old `#3` (ClientFileLogger duplicate) removed. Old `#7` (handleLog) → new `#4`. - **`console-file.tsx` entries unchanged**: old `#4`/`#6` → new `#3`/`#5`. These are artifacts of `console-file.tsx` intercepting the server process's terminal output, not from `handleLog` directly.
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.
No description provided.