Missing/broken sourcemaps for JS modules w/ imports when used with Vue

Describe the bug

I originally reported this to JetBrains, and they seem to think it’s an issue caused by sourcemaps not being generated by Vite. The same project moved over, running, and debugging on Vue-CLI does not have this issue and breakpoints are hit in the correct file.

https://youtrack.jetbrains.com/issue/WEB-55544

IntelliJ/WebStorm/VSCode seems to be unable to properly debug local JavaScript files when debugging JS modules imported into Vue components in a Vite project.

If you import a regular JS module into your component which itself has an import IJ/WS/VSC is unable to properly map the local .js file to the remote file for JavaScript debugging purposes due to missing/broken sourcemaps. When you place a breakpoint in your JS module source a new, read-only copy of the remote file is loaded from http://localhost:3000/src/xxx/xxx.js in the IDE and the breakpoint stops there instead of in the original JS file. This means that you have to debug in a read-only copy and then swap to your local copy for edits, which can be a big pain.

It looks like this only happens when the modules themselves have imports. You can see that the remote file has a changed “import” line and so that might be causing it to not match up. Here’s a screenshot from a sample project where the import inside the module causes the mismatch. You can see this difference between the local and “remote” on line 1.

I’ve also created an example project which replicates this issue.

https://github.com/Smef/vite-debug-issue-dem

Reproduction

https://github.com/Smef/vite-debug-issue-demo

System Info

System:
    OS: macOS 12.3.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 147.20 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 100.0.4896.88
    Firefox: 99.0.1
    Safari: 15.4
  npmPackages:
    @vitejs/plugin-vue: ^2.3.1 => 2.3.1 
    vite: ^2.9.5 => 2.9.5

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 https://github.com/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.

[BenceSzalai]

If this works, I think we only need to inject sourcemap when a query is injected (example: ?t=) and sourcemap is not generated by anything.

Sourcemap always have to be injected when there is a change made to any JS files, because otherwise the IDE cannot properly present the debugger. The initial request from the browser for a JS file imported into a Vue component (my test case) is without any query string. Of course, if I make a change and hot reload gets a new version of the file, a ?t=... query will be attached, but mapping to the original source file is needed also for the initially loaded file.

So the cases I see are:

1.) Contents of a file are not changed at all by Vite, just served as they are: no need for sourcemap, because the IDE will know based on path the correct file, and when the IDE compares the file seen by the Browser to the file it has will recognise they are the same - it is an assumption on my side, but this explains the behaviour I see, namely that if the file is edited in a way, that Vite does not have to make changes to it, the debugger works fine even without a sourcemap.

2.) Contents of a file are changed by Vite, but the changes are only rewritten imports: no need for an actual sourcemap, but needs a dummy sourcemap with an empty mappings, names etc, only having a one element sources array pointing at the original file. This will only work properly as long as no new lines are inserted or no lines are removed from the file. Here we can utilise the fact that the imports are fine to be different in the IDE and the browser as an import cannot be stepped into, and no other lines of the code are changed therefore when the IDE steps in the code it can show the proper line and position.

3.) Contents of a file are changed by Vite beyond only rewritten imports: In this case a full blown sourcemap is required for proper debugging. Without a sourcemap the IDE would show a read only copy of the served file (original issue) and if a minimal sourcemap is used as in 2. the IDE would show breakpoints at incorrect lines and character positions.

Now I’m not sure if Vite would ever do a type 3. change to a file during serving it in dev mode. As long as it is only 1. or 2. and we add the minimalistic sourcemap with only a single element source array pointing to the original source file, it should be okay. But in this case MagicString is not needed at all, simple string manipulation could be sufficient.

[BenceSzalai]

I can confirm it is working at least in my test case as shown above, with only setting the source in the map, without generating any mappings.

By the same token, if the overhead associated with generating an actual SourceMap is not welcome in dev mode (understandable), maybe importAnalysisPlugin should use just a regular string instead of a MagicString, as why to bear the overhead of collecting the changes if we don’t use them at the end anyway? (I don’t know actually how the overhead of using MagicString to manipulate the source vs. generating the proper map that includes mappings compares. It might be the case that the former is negligible overhead, but I don’t know. Was it tested/examined, or it may only be an illusion that not generating a map at the end solves the overhead, if prepend(), overwrite() etc calls to MagicString are also significantly slower than just splitting and concatenating standard srings. Not sure…)