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

Line numbers in TypeScript broken for Chrome/VSCode debugging #5834

Closed
7 tasks done
anselanza opened this issue Nov 25, 2021 · 8 comments
Closed
7 tasks done

Line numbers in TypeScript broken for Chrome/VSCode debugging #5834

anselanza opened this issue Nov 25, 2021 · 8 comments

Comments

@anselanza
Copy link

Describe the bug

I have a web application that does not use any frameworks such as React, Vue, etc. but does use TypeScript instead of normal JS files. When breakpoints are placed in my source code (using VSCode) the application does indeed break at the expected moment, and both Chrome Debugger and VSCode highlight the same (correct) lines but all Call Stack and variables info clearly shows the debugger is being referred to a different line. In addition, the line numbers reported for console.log statements (in Debug Console, for example) do not match the source code.

Reproduction

This is unfortunately tricky to reproduce because the problem seems to accumulate over a number of lines of code, and I'm not sure exactly where the misalignment happens. I will try to describe what I'm seeing as carefully as possible:

Line 201 is indeed the same line I set a breakpoint, and Chrome stops at this breakpoint and highlights the correct line:
Screenshot 2021-11-25 at 13 23 07

Back in VSCode, the same (correct) line is still highlighted and the breakpoint has not moved, BUT notice how the "Variables" pane is showing information relating to a function a few lines down (removeControlledPlayer):
Screenshot 2021-11-25 at 13 22 56

Notice how Chrome Debugger is doing the same thing - the Call Stack is showing the correct line number as per the sourcecode (201) but entirely the wrong function (removeControlledPlayer starts only from line 204 in the source code):
Screenshot 2021-11-25 at 13 23 12

In what I assume is related, the line numbers for nearby console.log statements are curiously out. For example, the string "pointerup: remove!" is attributed to line 195 in the logs:
Screenshot 2021-11-25 at 13 23 30

...But this statement actually appears on line 211 in the source code:
Screenshot 2021-11-25 at 13 23 38

When bundling the exact same source code using another bundler (in my case, Parcel) the debugger works as normal and line numbers do not misalign like this.

Is there something wrong in ESBuild sourcemaps for TypeScript, which is what I believe Vite uses for TypeScript transpilation?

System Info

System:
    OS: macOS 11.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
    Memory: 101.52 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.16.0 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 7.21.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 96.0.4664.55
    Firefox: 88.0.1
    Safari: 15.0
  npmPackages:
    vite: ^2.6.14 => 2.6.14

Used Package Manager

npm

Logs

No response

Validations

@cphillips
Copy link

In case it helps anyone, for my project removing multi-line imports worked around the issue.

import {
funcA,
funcB
} from './lib'

to

import { funcA, funcB } from './lib' 

@m430

This comment was marked as spam.

@winston0410

This comment was marked as spam.

@redplant3d

This comment was marked as spam.

@Flamenco
Copy link

Here is a regex that I used to find multiline imports in my IDE

^import .*\{[^\}]+$

@paxperscientiam
Copy link

paxperscientiam commented Jun 5, 2023

I can confirm that I too see this bug with v4.3.8 in FF and Safari.

I can also confirm that @cphillips's workaround works still.

@bluwy bluwy added the feat: sourcemap Sourcemap support label Jun 5, 2023
@dmoebius
Copy link

dmoebius commented Jun 6, 2023

Avoiding multi-line imports did not help in my case. Line numbers are totally off in stacktraces.

@github-actions
Copy link

Hello @anselanza. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with need reproduction will be closed if they have no activity within 3 days.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 18, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Jul 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants