Breakpoints lost in JS files with HRM

[JorgeRey-Lenio]

Describe the bug

Hi!

Trying vite with HRM I found that by adding a breakpoint (in the browser inspector) on a js file and then changing something in that file, the breakpoint is lost. This doesn't happen with JSX files. To try this I added a stackblitz where there is a counter.js file. Add a breakpoint on the js file and then modify something on it, the breakpoint will vanish.

Thanks.

Reproduction

https://stackblitz.com/edit/vitejs-vite-b4gczg

Steps to reproduce

Add a breakpoint to the counter.js file and then modify it.

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.2 - /usr/local/bin/npm
  npmPackages:
    vite: ^4.3.9 => 4.3.9

Used Package Manager

npm

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.

[stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitejs-vite-b4gczg (Open reproduction)

[patak-dev]

If we use TS for the counter module, then dev tools will place the breakpoint following source maps and even when the page is reloaded, it is properly maintained. Working reproduction: https://stackblitz.com/edit/vitejs-vite-z3ykwv

The original reproduction doesn't work because it is a .js file that doesn't have source maps. Chrome dev tools removes the breakpoint after HMR or page reload. @bmeurer, I know your team was looking into this. Could there be a regression? Or maybe we should force a sourcemap even if there isn't transpilation?

[bmeurer]

Thanks for looping me in here. I've created a minimal repro here.

From the DevTools perspective there's not a lot we can do: Prior to HMR, the breakpoint is set in counter.js, while after the HMR the counter.js is basically gone and replaced by counter.js?t=1686729364009. To the browser engine these are two different scripts, for good reasons, since the server could deliver completely different content based on query parameters, and it'd be unsound (and probably surprising in many cases) if we'd try to migrate breakpoints between scripts while ignoring query parameters.

I think the suggestion from @patak-dev to force sourcemaps even if no transpilation is necessary would be the ideal fix here. In that case the breakpoint is set on the source-mapped counter.js and will therefore properly transition from the originally deployed counter.js to the new deployed counter.js?t=1686729364009 after HMR, since DevTools will always keep the breakpoint on the most recent script that provides the source-mapped file.

cc @jaro-sevcik

[sapphi-red]

Closing as #13514 is merged.