Edge DevTools becomes completely unresponsive/frozen when connected to the Vite dev server starting from v8.1.0. Version 8.0.5 and below work perfectly

Describe the bug

Edge DevTools becomes completely unresponsive/frozen when connected to the Vite dev server starting from v8.1.0. Version 8.0.5 and below work perfectly.

Environment

Vite: 8.1.0 (broken) / 8.0.5 (working)
Edge: 版本 153.0.4234.48 (正式版本) (64 位)
Node: v26.8.1
OS: windows 10

Reproduction

pnpm create vite@latest test-app --template vue-ts
pnpm add vite@8.1.0 -D
pnpm dev
Open Edge DevTools (F12) → DevTools main thread freezes

Already ruled out (Clean environment)

❌ sourcemap: false → still freezes
❌ rolldown: false (fallback to esbuild) → still freezes
❌ Removed all unplugin/auto-import plugins → still freezes
❌ InPrivate mode (no extensions) → still freezes
❌ Clean Vue template (zero business code) → still freezes

Bisect result

vite@8.0.5 ✅ Smooth
vite@8.1.0 ❌ Freezes

Analysis

Since disabling Rolldown doesn't help, this is likely caused by Vite 8.1.0's Dev Server WebSocket/HMR protocol changes conflicting with Edge DevTools' Chromium fork implementation, rather than the bundler itself.

Reproduction

null

Steps to reproduce

No response

System Info

win10

Used Package Manager

pnpm

Logs

No response

Validations

Follow our Code of Conduct
Read the Contributing Guidelines.
Read the docs.
Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
The provided reproduction is a minimal reproducible example of the bug.

strip-deps-sourcemap.js
vite.config.js
import { stripDepsSourcemap } from "./plugins/strip-deps-sourcemap.js";
plugins: [stripDepsSourcemap ()]
After adding it, DevTools no longer lags.

I set up the same environment locally but couldn't reproduce the issue. I'm not sure what's missing. Could you provide the complete repository code and steps so I can give it another try?

1.pnpm create vite@latest demo
2. pnpm install element-plus
3. pnpm install -D unplugin-vue-components unplugin-auto-import
4. import { defineConfig } from 'vite'
import AutoImport from 'unplugin-auto-import/vite'
import Components from 'unplugin-vue-components/vite'
import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'

export default defineConfig({
// ...
plugins: [
// ...
AutoImport({
resolvers: [ElementPlusResolver()],
}),
Components({
resolvers: [ElementPlusResolver()],
}),
],
})
5.run demo in vs code ,pnpm dev
6.Open the developer tools panel in Edge browser
7.Check the network panel
8. Press F5 on the keyboard
9. now it can not work.Lag.
10. My browser version number is 153.0.4234.48 official version X64

By the way, use a component to app.vue, such as el-button

#23561 (comment)
I still cannot reproduce the issue on my local Edge browser, but I have reduced the size of loading element-plus separately. You can try installing the modifications from this pull request and verify locally whether the issue has been resolved.

Second, independent reproduction from a different (larger) project — plus the trigger that I think explains why this doesn't reproduce locally.

The trigger is Edge DevTools parsing source maps

In Edge DevTools: F1 → Preferences → Sources → "Enable JavaScript source maps".

Unchecked → vite 8.3.0 is completely usable, including F5 with the Network panel open.
Checked → it freezes again immediately, every time.

So it is not the dev server, not the HMR/WebSocket protocol and not the bundler: it's DevTools parsing the source maps the dev server serves. Which is probably why it doesn't reproduce on a machine where that preference happens to be off — worth checking the state of that toggle before retrying.

A/B on one machine, same codebase

Two dev servers from the same code, same Edge window, same profile, same extensions, no InPrivate — only the port differs:

vite 7.3.6 → Network panel renders fine.
vite 8.3.0 → Network panel blank, DevTools main thread frozen.
Same machine, same port, Chrome → unaffected.

Switching the port switches the behavior, 100% reproducible. This also confirms it is still present in 8.3.0 (the OP bisected 8.1.0 as the first broken release).

Environment


OS	Windows (build 10.0.26200)
Browser	Microsoft Edge 153.0.4234.48 (64-bit)
Node	v24.19.0
Package manager	pnpm 11.7.0
Broken	vite 8.3.0
Fine	vite 7.3.6
Stack	vue 3.5.42, element-plus 2.14.5, unplugin-auto-import 21.1.0, unplugin-vue-components 32.1.0, vite-plugin-vue-devtools 8.2.1

Why `sourcemap: false` doesn't help

In dev, responses carry inline base64 maps regardless of build.sourcemap / server.sourcemap. The injection happens at response time in send() (vite/dist/node/chunks/node.js), so neither config nor a plugin transform can turn it off:

// send(): a real map gets inlined ...
if (map && "version" in map && map.mappings)
  content = getCodeWithSourcemap(type, content.toString(), map);
// ... and otherwise a fallback map with the full original content is synthesized
else if (type === "js" && (!map || map.mappings !== ""))
  content = getCodeWithSourcemap(type, code, new MagicString(code).generateMap({
    source: ..., hires: "boundary", includeContent: true
  }));

function genSourceMapUrl(map) {
  if (typeof map !== "string") map = JSON.stringify(map);
  return `data:application/json;base64,${Buffer.from(map).toString("base64")}`;
}

Measured on the served responses:

/@vite/client: 210,926 bytes over 1,274 lines, longest single line 171,054 chars.
One prebundled dep chunk: 1,641,350 bytes, longest single line 1,102,006 chars.
Every dep JS response we checked contained exactly one sourceMappingURL=data:application/json;base64,....

The map is a data: URL, so that payload must sit on one line — hundreds of KB to ~1 MB per response, including /@vite/client on every page load.

A prediction worth testing

Since /@vite/client alone carries a 171k-char line, I'd expect the bare vue-ts template from the OP's steps to freeze too, as long as "Enable JavaScript source maps" is on — no element-plus needed. If that holds, it separates "element-plus payload size" from "any dev response is enough".

On #23561

The direction matches what I'm seeing. One note: sourcemapUrl is only set on the optimized-dep branch of transformMiddleware, so /@vite/client and other non-dep modules still take the inline path in send(). If the freeze is driven by the single-line payload size, that path presumably still triggers it. I'll install the PR build locally and report back.

中文版

触发点是 DevTools 解析 source map

在 Edge DevTools 里：F1 → 偏好设置 → 来源 → 取消勾选「启用 JavaScript 源映射」。

取消勾选后：vite 8.3.0 完全可用，开着网络面板按 F5 也不卡。
重新勾上：立刻再次卡死。

所以问题不在 dev server、不在 HMR/WebSocket 协议、也不在打包器 —— 是 Edge 的 DevTools 在解析 dev server 返回的 source map。这大概就是本地复现不出来的原因：那台机器上这个开关正好是关的。重试之前值得先确认一下这个开关的状态。

同一台机器上的 A/B 对照

同一套代码起了两个 dev server，同一个 Edge 窗口、同一个配置文件、同样的扩展、没用 InPrivate，只有端口不同：

vite 7.3.6 → DevTools 网络面板正常渲染。
vite 8.3.0 → 打开 DevTools 且停在网络面板时，面板一片空白，DevTools 主线程卡死。
同机同端口用 Chrome 打开则完全正常。

换端口，现象就跟着换，100% 可复现。这也说明 8.3.0 上仍然存在（原报告 bisect 出的首个异常版本是 8.1.0）。

环境


系统	Windows (build 10.0.26200)
浏览器	Microsoft Edge 153.0.4234.48 (64 位)
Node	v24.19.0
包管理器	pnpm 11.7.0
异常版本	vite 8.3.0
正常版本	vite 7.3.6
依赖栈	vue 3.5.42、element-plus 2.14.5、unplugin-auto-import 21.1.0、unplugin-vue-components 32.1.0、vite-plugin-vue-devtools 8.2.1

为什么 `sourcemap: false` 没有用

dev 模式下这些响应带的是内联 base64 map，且不受 build.sourcemap / server.sourcemap 控制。注入发生在响应阶段 send() 里（vite/dist/node/chunks/node.js），所以配置项和插件 transform 阶段都关不掉它：

// send()：有 map 就内联……
if (map && "version" in map && map.mappings)
  content = getCodeWithSourcemap(type, content.toString(), map);
// ……没有 map 就现造一个（includeContent: true，把源文件内容一起塞进去）再内联
else if (type === "js" && (!map || map.mappings !== ""))
  content = getCodeWithSourcemap(type, code, new MagicString(code).generateMap({
    source: ..., hires: "boundary", includeContent: true
  }));

function genSourceMapUrl(map) {
  if (typeof map !== "string") map = JSON.stringify(map);
  return `data:application/json;base64,${Buffer.from(map).toString("base64")}`;
}

实测返回内容：

/@vite/client：210,926 字节 / 1,274 行，最长单行 171,054 字符。
某个预打包依赖 chunk：1,641,350 字节，最长单行 1,102,006 字符。
我们抽查的每个依赖 JS 响应里都恰好带一处 sourceMappingURL=data:application/json;base64,...。

因为 map 是 data: URL，这一大坨只能压在一行里 —— 每个响应几百 KB 到约 1 MB，包括每次页面加载都会请求的 /@vite/client。

一个值得验证的预测

/@vite/client 单行就有 171k 字符，所以我预计原报告步骤里那个干净的 vue-ts 模板也会卡，只要「启用 JavaScript 源映射」是开着的，不需要 element-plus。如果成立，就能把「element-plus 体积」和「任意 dev 响应就够触发」这两件事区分开。

关于 #23561

方向和我观察到的一致。有一点：sourcemapUrl 只在 transformMiddleware 的优化依赖分支里设置，所以 /@vite/client 和其他非依赖模块仍然走 send() 的内联分支。如果卡顿是单行 payload 长度导致的，这条路径应该还是会触发。我会在本地装上这个 PR 构建后回报。

I have the same problem with Vite 8.2.0. I have another project with 7.3.1 and no problem
If I print hello world than it works as soon as I use Auth0 SDK, Ant Design component dev tool freeze

me too!

@btea

Hi guys , Vite's dev server currently inlines the sourcemap as a base64 data: URI for the response. For bigger responses like /@vite/client and optimized dep chunks, this can turn into a single line that's hundreds of KB or even over 1MB long. Seems like this is what causes Edge DevTools to freeze when it tries to parse the response, which also matches the measurements mentioned in the comments above.

I noticed @btea's #23561 already fixes the same issue for optimized deps specifically. I opened a PR using the same approach, but extended it to the other dev responses as well, including regular modules, /@vite/client, and direct CSS requests, since those can still hit the same issue based on the reports here.

If anyone is still hitting this, would appreciate it if you could try the PR and let me know if it helps, especially those who already have a solid repro.

Also tagging @btea since this overlaps with #23561. Didn't want to silently duplicate the work, so thought it'd be better to make the connection clear.

Second, independent reproduction from a different (larger) project — plus the trigger that I think explains why this doesn't reproduce locally.

The trigger is Edge DevTools parsing source maps

In Edge DevTools: F1 → Preferences → Sources → "Enable JavaScript source maps".
* Unchecked → vite 8.3.0 is completely usable, including F5 with the Network panel open. * Checked → it freezes again immediately, every time.
So it is not the dev server, not the HMR/WebSocket protocol and not the bundler: it's DevTools parsing the source maps the dev server serves. Which is probably why it doesn't reproduce on a machine where that preference happens to be off — worth checking the state of that toggle before retrying.

A/B on one machine, same codebase

Two dev servers from the same code, same Edge window, same profile, same extensions, no InPrivate — only the port differs:

vite 7.3.6 → Network panel renders fine.

vite 8.3.0 → Network panel blank, DevTools main thread frozen.

Same machine, same port, Chrome → unaffected.

Switching the port switches the behavior, 100% reproducible. This also confirms it is still present in 8.3.0 (the OP bisected 8.1.0 as the first broken release).

Environment

OS Windows (build 10.0.26200)
Browser Microsoft Edge 153.0.4234.48 (64-bit)
Node v24.19.0
Package manager pnpm 11.7.0
Broken vite 8.3.0
Fine vite 7.3.6
Stack vue 3.5.42, element-plus 2.14.5, unplugin-auto-import 21.1.0, unplugin-vue-components 32.1.0, vite-plugin-vue-devtools 8.2.1

Why sourcemap: false doesn't help

In dev, responses carry inline base64 maps regardless of build.sourcemap / server.sourcemap. The injection happens at response time in send() (vite/dist/node/chunks/node.js), so neither config nor a plugin transform can turn it off:

// send(): a real map gets inlined ...
if (map && "version" in map && map.mappings)
content = getCodeWithSourcemap(type, content.toString(), map);
// ... and otherwise a fallback map with the full original content is synthesized
else if (type === "js" && (!map || map.mappings !== ""))
content = getCodeWithSourcemap(type, code, new MagicString(code).generateMap({
source: ..., hires: "boundary", includeContent: true
}));

function genSourceMapUrl(map) {
if (typeof map !== "string") map = JSON.stringify(map);
return data:application/json;base64,${Buffer.from(map).toString("base64")};
}
Measured on the served responses:

/@vite/client: 210,926 bytes over 1,274 lines, longest single line 171,054 chars.

One prebundled dep chunk: 1,641,350 bytes, longest single line 1,102,006 chars.

Every dep JS response we checked contained exactly one sourceMappingURL=data:application/json;base64,....

The map is a data: URL, so that payload must sit on one line — hundreds of KB to ~1 MB per response, including /@vite/client on every page load.

A prediction worth testing

Since /@vite/client alone carries a 171k-char line, I'd expect the bare vue-ts template from the OP's steps to freeze too, as long as "Enable JavaScript source maps" is on — no element-plus needed. If that holds, it separates "element-plus payload size" from "any dev response is enough".

On #23561

The direction matches what I'm seeing. One note: sourcemapUrl is only set on the optimized-dep branch of transformMiddleware, so /@vite/client and other non-dep modules still take the inline path in send(). If the freeze is driven by the single-line payload size, that path presumably still triggers it. I'll install the PR build locally and report back.

中文版

触发点是 DevTools 解析 source map

在 Edge DevTools 里：F1 → 偏好设置 → 来源 → 取消勾选「启用 JavaScript 源映射」。
* 取消勾选后：vite 8.3.0 完全可用，开着网络面板按 F5 也不卡。 * 重新勾上：立刻再次卡死。
所以问题不在 dev server、不在 HMR/WebSocket 协议、也不在打包器 —— 是 Edge 的 DevTools 在解析 dev server 返回的 source map。这大概就是本地复现不出来的原因：那台机器上这个开关正好是关的。重试之前值得先确认一下这个开关的状态。

同一台机器上的 A/B 对照

同一套代码起了两个 dev server，同一个 Edge 窗口、同一个配置文件、同样的扩展、没用 InPrivate，只有端口不同：

vite 7.3.6 → DevTools 网络面板正常渲染。

vite 8.3.0 → 打开 DevTools 且停在网络面板时，面板一片空白，DevTools 主线程卡死。

同机同端口用 Chrome 打开则完全正常。

换端口，现象就跟着换，100% 可复现。这也说明 8.3.0 上仍然存在（原报告 bisect 出的首个异常版本是 8.1.0）。

环境

系统 Windows (build 10.0.26200)
浏览器 Microsoft Edge 153.0.4234.48 (64 位)
Node v24.19.0
包管理器 pnpm 11.7.0
异常版本 vite 8.3.0
正常版本 vite 7.3.6
依赖栈 vue 3.5.42、element-plus 2.14.5、unplugin-auto-import 21.1.0、unplugin-vue-components 32.1.0、vite-plugin-vue-devtools 8.2.1

为什么 sourcemap: false 没有用

dev 模式下这些响应带的是内联 base64 map，且不受 build.sourcemap / server.sourcemap 控制。注入发生在响应阶段 send() 里（vite/dist/node/chunks/node.js），所以配置项和插件 transform 阶段都关不掉它：

// send()：有 map 就内联……
if (map && "version" in map && map.mappings)
content = getCodeWithSourcemap(type, content.toString(), map);
// ……没有 map 就现造一个（includeContent: true，把源文件内容一起塞进去）再内联
else if (type === "js" && (!map || map.mappings !== ""))
content = getCodeWithSourcemap(type, code, new MagicString(code).generateMap({
source: ..., hires: "boundary", includeContent: true
}));

function genSourceMapUrl(map) {
if (typeof map !== "string") map = JSON.stringify(map);
return data:application/json;base64,${Buffer.from(map).toString("base64")};
}
实测返回内容：

/@vite/client：210,926 字节 / 1,274 行，最长单行 171,054 字符。

某个预打包依赖 chunk：1,641,350 字节，最长单行 1,102,006 字符。

我们抽查的每个依赖 JS 响应里都恰好带一处 sourceMappingURL=data:application/json;base64,...。

因为 map 是 data: URL，这一大坨只能压在一行里 —— 每个响应几百 KB 到约 1 MB，包括每次页面加载都会请求的 /@vite/client。

一个值得验证的预测

/@vite/client 单行就有 171k 字符，所以我预计原报告步骤里那个干净的 vue-ts 模板也会卡，只要「启用 JavaScript 源映射」是开着的，不需要 element-plus。如果成立，就能把「element-plus 体积」和「任意 dev 响应就够触发」这两件事区分开。

关于 #23561

方向和我观察到的一致。有一点：sourcemapUrl 只在 transformMiddleware 的优化依赖分支里设置，所以 /@vite/client 和其他非依赖模块仍然走 send() 的内联分支。如果卡顿是单行 payload 长度导致的，这条路径应该还是会触发。我会在本地装上这个 PR 构建后回报。

Thank you.You are right. Close the "Enable JavaScript source maps", devtools works.

Edge is tracking this as MicrosoftEdge/DevTools#462. The Edge team released a fix in Canary 158.0.4343.0. I confirmed that it solves the freeze for me with Vite 8.3.0 and JavaScript source maps turned on.

Edge's built-in Unminification extension asks DevTools for every source file. Before each answer, DevTools calls new URL() on that file's source map URL. With Vite's inline maps, that URL is the whole base64 map of the bundle the file came from.

So for me that URL is up to 2.8 MB and in total the devtools was parsing 1 GB of URLs.

External maps (#23561) still help: they keep each source map URL short for any DevTools extension that checks it.

Confirmed on Edge Stable 156.0.4314.50 with Vite 8.1.0 (React)

I can confirm that this issue is still reproducible on Microsoft Edge Stable 156.0.4314.50 (64-bit) as of October 27, 2026.

I'm experiencing the same problem while developing a React application with Vite.

Environment

OS: Windows
Browser: Microsoft Edge 156.0.4314.50 (Official build, 64-bit)
Vite: 8.1.0
@vitejs/plugin-react: 6.0.2
Vitest: 4.1.9
Development server: http://localhost:5173
Framework: React

Observed behavior

When opening Microsoft Edge DevTools on the local Vite development server:

The Network panel remains completely blank.
Network requests are not displayed, even after refreshing the page.
Other DevTools panels and settings may also become unresponsive.
The application itself continues rendering normally.
DevTools works correctly on other websites.

Troubleshooting results

Working workaround

Disabling source maps under:

DevTools → Settings → Preferences → Sources

restores DevTools functionality. The Network panel becomes responsive and displays requests again.

I have not yet isolated whether disabling JavaScript source maps alone is sufficient or whether CSS source maps also contribute.

Additional observations

The issue still occurs in a recent Edge Stable release, even though a fix was reportedly confirmed in Edge Canary 158.0.4343.0.

My results appear consistent with the source map processing issue discussed in this thread.

An additional difference in my environment is that Edge InPrivate mode works correctly, while the normal browser profile remains affected even with all extensions disabled.

I hope these additional environment details help confirm and track the issue.

Related: MicrosoftEdge/DevTools#462

Edge DevTools becomes completely unresponsive/frozen when connected to the Vite dev server starting from v8.1.0. Version 8.0.5 and below work perfectly #23549

Description

Describe the bug

Describe the bug

Environment

Reproduction

Already ruled out (Clean environment)

Bisect result

Analysis

Reproduction

Steps to reproduce

System Info

Used Package Manager

Logs

Validations

Activity

king123715 commented on Sep 22, 2026

king123715 commented on Sep 22, 2026

btea commented on Sep 22, 2026

king123715 commented on Sep 23, 2026

king123715 commented on Sep 23, 2026

btea commented on Sep 24, 2026

Mxy041006 commented on Sep 24, 2026

The trigger is Edge DevTools parsing source maps

A/B on one machine, same codebase

Environment

Why sourcemap: false doesn't help

A prediction worth testing

On #23561

触发点是 DevTools 解析 source map

同一台机器上的 A/B 对照

环境

为什么 sourcemap: false 没有用

一个值得验证的预测

关于 #23561

sagarcsnsw commented on Sep 25, 2026

490626721 commented on Sep 26, 2026

jhjh1214 commented on Sep 27, 2026

king123715 commented on Sep 28, 2026

The trigger is Edge DevTools parsing source maps

A/B on one machine, same codebase

Environment

Why sourcemap: false doesn't help

A prediction worth testing

On #23561

触发点是 DevTools 解析 source map

同一台机器上的 A/B 对照

环境

为什么 sourcemap: false 没有用

一个值得验证的预测

关于 #23561

nickbabcock commented on Oct 17, 2026

sezeryigitt commented on Oct 27, 2026

Confirmed on Edge Stable 156.0.4314.50 with Vite 8.1.0 (React)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Why `sourcemap: false` doesn't help

为什么 `sourcemap: false` 没有用

Why `sourcemap: false` doesn't help

为什么 `sourcemap: false` 没有用