Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: breakpoints in JS not working #13514

Merged
merged 6 commits into from
Aug 22, 2023

Conversation

sapphi-red
Copy link
Member

Description

I once struggled making this work without adding a big overhead caused by generating sourcemaps (#9476).
This time I came up with a solution using //# sourceURL.

I tested this with #13503 on Chrome and Firefox (Windows) and it worked for me.

This doesn't work with VSCode's debugger. 😢

Additional context


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the PR Title Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

@sapphi-red sapphi-red added the p3-minor-bug An edge case that only affects very specific usage (priority) label Jun 14, 2023
@stackblitz
Copy link

stackblitz bot commented Jun 14, 2023

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

@patak-dev
Copy link
Member

Nice! If this isn't a regression for VS Code, I think we can merge it and get some mileage from users in the 4.4 beta.

One thing I see is that the source is being applied to some files where it doesn't help. I imagine it isn't hurting though, but we could try to apply it only if the sourceURL points to a real file? Or maybe this would later be useful with virtual modules too?
From https://vite.new/vue:

  1. //# sourceURL=/src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.css
  2. //# sourceURL=/src/style.css

In the second case, it points to a real file but adding a breakpoint isn't useful. Still, I don't think it would hurt having the comment there. About 1., should it point to /src/App.vue?

@bmeurer
Copy link
Contributor

bmeurer commented Jun 15, 2023

I know this sounds obvious and like a great solution and @jaro-sevcik and I discussed this as well yesterday and whether we should recommend this as a fix. However, this isn't going to work as you expect it to work (with Chrome), because //# sourceURL (unlike //# sourceMappingURL) is handled by V8 (the back-end) while source maps are handled purely by the DevTools front-end. The implication is that if you have multiple scripts with a clashing //# sourceURL (intentionally clashing in the case of HMR), a breakpoint will be set in all of these scripts by V8, which is not what you want. Ideally only the last script would be around with HMR, but often you have state that keeps the previous versions of the script alive as well, and you'll stop in random places, which leads to a very confusing developer experience.

While this is more of an implementation detail of V8/Chrome, and I think we could also change it over time (although the specified behavior for //# sourceURL is even more vague than for source maps), I'd strongly encourage to go with identity source maps instead for now. They are extremely cheap to generate (you're merely adding couple milliseconds, which in the grand scheme of things doesn't matter) and will provide a consistent experience to developers.

@sapphi-red
Copy link
Member Author

If this isn't a regression for VS Code,

It's a partial regression. Without this PR, the breakpoints work if that file is not changed. But with this PR, the breakpoints don't work even if that file is not changed.

However, this isn't going to work as you expect it to work (with Chrome),

I'd strongly encourage to go with identity source maps instead for now.

I see. To generate an identity source map, Vite will have to tokenize the content of the file and generate the mappings field. Or skip the tokenization and generate the mapping field with the every character in the file. Is there a better way than this?

@bmeurer
Copy link
Contributor

bmeurer commented Jun 16, 2023

To generate an identity source map, Vite will have to tokenize the content of the file and generate the mappings field. Or skip the tokenization and generate the mapping field with the every character in the file. Is there a better way than this?

I'd use a naive approach and just generate a mapping for every whitespace/word boundary (poor mans tokenization).

@sapphi-red sapphi-red force-pushed the fix/js-breakpoints-not-working branch from 3e6073c to cc70dd4 Compare August 12, 2023 08:01
@sapphi-red sapphi-red marked this pull request as ready for review August 12, 2023 08:01
@sapphi-red
Copy link
Member Author

I updated the PR to inject //# sourceMappingURL=data:* to every file unless { mappings: '' } is returned. I used hires: 'boundary' to generate the identity sourcemap as suggested.

I tested this with Chrome and Firefox and VSCode debugger on Windows. It worked fine.

plugins: [...createNodePlugins(false, false, false), bundleSizeLimit(120)],
plugins: [...createNodePlugins(false, false, false), bundleSizeLimit(150)],
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's now 149kB because magic-string is now bundled in the CJS build.

Comment on lines +66 to +74
if (type === 'js' && (!map || map.mappings !== '')) {
const urlWithoutTimestamp = removeTimestampQuery(req.url!)
const ms = new MagicString(content.toString())
content = getCodeWithSourcemap(
type,
content.toString(),
ms.generateMap({ source: urlWithoutTimestamp, hires: 'boundary' }),
)
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is the main part of the change. Other changes are to pass { mappings: '' } as-is to this part.

@@ -31,7 +31,7 @@ const debugCache = createDebugger('vite:cache')

export interface TransformResult {
code: string
map: SourceMap | null
map: SourceMap | { mappings: '' } | null
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is a breaking change.
But this type was not correctly declared and actually transformRequest could return { mappings: '' } if a load hook returned a map with that and no transform hook transformed that request.

Comment on lines +569 to 576
// { mappings: '' }
if ((m as SourceMap).mappings === '') {
combinedMap = { mappings: '' }
break
}
// empty, nullified source map
combinedMap = this.combinedMap = null
this.sourcemapChain.length = 0
combinedMap = null
break
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part was not correct. { mappings: '' } is different from null. So it shouldn't be changed to null.
For example, if this.sourcemapChain is [{ mappings: '' }, validSourcemap], the combined result should be { mappings: '' } instead of validSourcemap.

@sapphi-red
Copy link
Member Author

/ecosystem-ci run

@vite-ecosystem-ci
Copy link

vite-ecosystem-ci bot commented Aug 12, 2023

📝 Ran ecosystem CI: Open

suite result
analogjs ✅ success
astro ✅ success
histoire ✅ success
ladle ✅ success
laravel ✅ success
marko ✅ success
nuxt ❌ failure
nx ✅ success
previewjs ✅ success
qwik ✅ success
rakkas ✅ success
sveltekit ✅ success
unocss ❌ failure
vite-plugin-pwa ✅ success
vite-plugin-ssr ✅ success
vite-plugin-react ✅ success
vite-plugin-react-pages ❌ failure
vite-plugin-react-swc ✅ success
vite-plugin-svelte ❌ failure
vite-plugin-vue ✅ success
vite-setup-catalogue ✅ success
vitepress ✅ success
vitest ❌ failure

@sapphi-red
Copy link
Member Author

nuxt, unocss, vite-plugin-react-pages are failing on main too.
vite-plugin-svelte is failing because of the snapshot mismatch that is expected.
vitest is failing with the type mismatch (#13514 (comment)).

patak-dev
patak-dev previously approved these changes Aug 14, 2023
Copy link
Member

@patak-dev patak-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a good idea to merge this one soon so other folks will test it during the Vite 5 beta. @bluwy go for it if you are good with these changes.

@bluwy
Copy link
Member

bluwy commented Aug 21, 2023

Just reviewed this. LGTM 👍 Feel free to merge this once the conflicts are resolved @sapphi-red. Looks like it's caused by #14061, so the bundle limit numbers might change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat: hmr p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants