Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix getVersionInfo fails behind corporate firewalls [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#85071•Fetched 2026-04-08 02:17:31
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
jameskrausjameskraus
Participants
jameskrausjameskraus
Timeline (top)
issue_type_added ×1renamed ×1

Error Message

SyntaxError: Unexpected token '<', "

<!DOCTYPE "... is not valid JSON at JSON.parse (<anonymous>)

Root Cause

It emits a confusing JSON parse warning during development because npm's registry is blocked by a corporate firewall:

PR fix notes

PR #67309: perf: improve retrieving versionInfo on Turbo HMR

Description (problem / solution / changelog)

Why?

Identified the bottleneck of Turbopack HMR, one of the reason is that we run execSync to get user's package manager and fetch their registry to get the latest & canary version of Next.js. This process was located at the initial of HMR, which could have been delayed to the initial of the error handling.

How?

  • Remove getting user's package manager and just fetch from NPM regardless the user uses Yarn.
  • Used an async IIFE to await the promise of getVerionInfo value inside the synchronous ws.handleUpgrade.

Benchmark

Benchmarked with console inside try-finally

Webpack -- no cache

VersionReady
Canary1185ms
Delta896ms
Delta Webpack vs Canary Webpack-24.39%

Turbopack

VersionReady
Canary1002ms
Delta (Turbopack)509ms
Delta Turbopack vs Canary Turbopack-49.20%

Changed files

  • packages/next/src/server/dev/hot-reloader-turbopack.ts (modified, +13/-10)
  • packages/next/src/server/dev/hot-reloader-webpack.ts (modified, +2/-3)

Code Example

SyntaxError: Unexpected token '<', "
<!DOCTYPE "... is not valid JSON
    at JSON.parse (<anonymous>)

---

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Aug 11 21:15:09 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6041
  Available memory (MB): 131072
  Available CPU cores: 16
Binaries:
  Node: 22.17.1
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.14.0
Relevant Packages:
  next: 15.5.4 // There is a newer version (15.5.6) available, upgrade recommended!
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.3
Next.js Config:
  output: N/A
 ⚠ There is a newer version (15.5.6) available, upgrade recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/vercel-labs/chatgpt-apps-sdk-nextjs-starter

To Reproduce

Run pnpm dev while npm's registry is blocked due to corporate firewall.

Current vs. Expected behavior

It emits a confusing JSON parse warning during development because npm's registry is blocked by a corporate firewall:

SyntaxError: Unexpected token '<', "
<!DOCTYPE "... is not valid JSON
    at JSON.parse (<anonymous>)
<img width="852" height="266" alt="Image" src="https://github.com/user-attachments/assets/8e5df4e6-21cc-4553-92ea-9e01db7c69b3" />

This error should not happen on pnpm dev, and instead it should use the registry specified in npmrc to fetch the latest tags.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Aug 11 21:15:09 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6041
  Available memory (MB): 131072
  Available CPU cores: 16
Binaries:
  Node: 22.17.1
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.14.0
Relevant Packages:
  next: 15.5.4 // There is a newer version (15.5.6) available, upgrade recommended!
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.3
Next.js Config:
  output: N/A
 ⚠ There is a newer version (15.5.6) available, upgrade recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.

Which area(s) are affected? (Select all that apply)

Not sure

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

This issue was introduced by https://github.com/vercel/next.js/pull/67309, which was intended to speed up startups.

Perhaps dev could fallback to the npmrc's registry if the attempt to directly use npm's registry didn't work? Just throwing out an idea.

extent analysis

TL;DR

The issue can be resolved by configuring pnpm to use the registry specified in the .npmrc file when the default registry is blocked.

Guidance

  • Check the .npmrc file to ensure it contains the correct registry URL.
  • Verify that the pnpm configuration is set to use the registry from the .npmrc file by running pnpm config get registry.
  • Consider adding a fallback mechanism to use the .npmrc registry when the default registry is blocked, as suggested in the additional context.
  • Try upgrading to the latest version of next (15.5.6) to see if the issue is resolved, as recommended in the environment information.

Example

No code snippet is provided as it is not clearly supported by the issue.

Notes

The issue seems to be related to the corporate firewall blocking the default npm registry, causing pnpm to fail when trying to fetch packages. The solution involves configuring pnpm to use the registry specified in the .npmrc file.

Recommendation

Apply workaround: Configure pnpm to use the registry from the .npmrc file when the default registry is blocked, as this is a more immediate solution to the problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#retriever error#indexing error#inference speed#output truncation#response parsing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

nextjs - ✅(Solved) Fix getVersionInfo fails behind corporate firewalls [1 pull requests, 1 participants]