Debugging in VS Code highlights wrong code line

[raiskila]

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes

Which terms did you search for in User Guide?

VS Code debugging

Environment

  System:
    OS: macOS 10.14.2
    CPU: x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
  Binaries:
    Node: 10.13.0 - ~/.nvm/versions/node/v10.13.0/bin/node
    npm: 6.4.1 - ~/.nvm/versions/node/v10.13.0/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 63.0.1
    Safari: 12.0.2
  npmPackages:
    react: ^16.6.3 => 16.6.3 
    react-dom: ^16.6.3 => 16.6.3 
    react-scripts: 2.1.1 => 2.1.1 
  npmGlobalPackages:
    create-react-app: Not Found

Steps to Reproduce

TL;DR: Debug a CRA app in the VS Code debugger and break on a breakpoint or debugger; statement. When clicking on a stack frame in the call stack that's inside react-dom.development.js, the highlighted line of code is wrong.

1. Install VS Code 1.30.0 or 1.31.0-insider and the Debugger for Chrome extension version 4.11.1.
2. npx create-react-app debugging-test
3. Copy the suggested launch.json file from CRA documentation into a newly created .vscode directory inside the project.
4. Add debugger; to the beginning of the render() method in App.js.
5. npm start
6. Hit F5 in VS Code to launch Chrome and start debugging.
7. After the debugger pauses, select the second-topmost stack frame (finishClassComponent in react-dom.development.js). Observe the highlighted line of code.

Expected Behavior

The correct line of code inside the finishClassComponent function is highlighted, like in Chrome Dev Tools:

Actual Behavior

An incorrect line of code is highlighted.

This issue is related to source mapping.

The number of the highlighted line is the same in Chrome Dev Tools and VS Code, but the source code displayed in Chrome Dev Tools, which is derived from source maps, is different. react-dom.development.js has 20,749 lines of code in Chrome, but the actual file shown in VS Code has 19,727 lines.

The extent to which this issue duplicates #5319 is unclear to me. It's not about testing, and doesn't seem to relate to breakpoint location. Rather it's about the code reconstructed from the source maps being different from the actual source and the VS Code debugger being tripped by this. The problem can also be reproduced by calling some code in react-dom and manually stepping into it.

For what it's worth, I tried adding the "disableOptimisticBPs": true option suggested in #5319 to launch.json, but it doesn't seem to be a valid option when "type" is "chrome".

Reproducible Demo

Repro repo

[justingrant]

I'm seeing the same issue. This bug makes VSCode useless for debugging any node_modules code, because you won't be able to step-through, use breakpoints, or do anything that depends on accurately knowing line numbers of code in the debugger. Huge problem.

I did a brief investigation of the issue and here's what I noticed:

1. As @jraiskila noted, the problem is that different code is at different line numbers between Chrome Dev Tools and VSCode.

2. The difference in line numbers seems to be entirely caused by differences in whitespace handling. The code is the same in both cases, but the code shown in Chrome has much more extra whitespace than the file stored on disk. For example, look at the top of the react-dom-development.js file in Chrome vs. the VS-Code Debugger (using the OPs repro steps above):

Chrome:

/** @license React v16.6.1
 * react-dom.development.js
 *
 * Copyright (c) Facebook, Inc. and its affiliates.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */
'use strict';

if (process.env.NODE_ENV !== "production") {
  (function () {
    'use strict';

    var React = require('react');

    var _assign = require('object-assign');

    var checkPropTypes = require('prop-types/checkPropTypes');

    var scheduler = require('scheduler');

    var tracing = require('scheduler/tracing');

And here's the VSCode version, which is the actual file stored on disk: (FWIW, this is also what you'll see if you use Chrome Dev Tools to open the react-dom.development.js file on disk)

/** @license React v16.6.1
 * react-dom.development.js
 *
 * Copyright (c) Facebook, Inc. and its affiliates.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

'use strict';



if (process.env.NODE_ENV !== "production") {
  (function() {
'use strict';

var React = require('react');
var _assign = require('object-assign');
var checkPropTypes = require('prop-types/checkPropTypes');
var scheduler = require('scheduler');
var tracing = require('scheduler/tracing');

3. It's not just line numbers that are different, it's also intra-line whitespace. The on-disk file has less indentation than the code shown in Chrome. This is less impactful than line numbering, but I assume that this would break columnar breakpoints. Example:

On-disk:

var React = require('react');

Chrome dev tools:

    var React = require('react');

4. All of the above was reproed on a Mac. At first I was suspicious that the cause might be PC-vs-Unix line endings issues, but given that the entire software stack here including Babel, CRA, and Chrome are all developed on non-Windows environments, I doubt that this is the cause.

[roblourens]

This could probably be moved to the vscode repo. This is happening because the file on disk is bundled (and reformatted, I guess) with its new content included in the sourcemap. But the path for the file in the sourcemap is just the path to the original file on disk. vscode thinks it has located the real file, so it shows you the file on disk which has the wrong line numbers. This is sort of a longstanding issue and I don't have a good fix right now.

A workaround on create-react-app's side would be to not do whatever transformations it's doing on this file, since they seem to only be formatting-related. The file actually ends up bigger as a result. But it's not something that CRA should "have" to do.

[justingrant]

Thanks @roblourens. If this is a longstanding issue in VSCode, is there already a VSCode issue in GitHub that I can watch? If not, I'll create one.

What I don't understand is why Chrome's debugger doesn't have the same problem but VSCode does have the problem. Is the reason that VSCode (unlike Chrome) lacks the ability, during debugging, to show HTTP responses that don't correspond to an existing source file on disk? If not, what's the root cause?

Regardless of root cause, it sounds like fixing this on the VSCode side is unlikely to happen soon, so it seems like the most logical fix is to, as you suggested, change create-react-app to "not do whatever transformations it's doing on this file, since they seem to only be formatting-related". Especially if those transformations are making create-react-app source files bigger than they need to be!

[roblourens]

I don't know of an existing issue that covers exactly this so you could create one, but I'm not likely to make any changes here in the near future. From my perspective, vscode is doing the right thing and the sourcemap is wrong.

What I don't understand is why Chrome's debugger doesn't have the same problem but VSCode does have the problem

Chrome devtools only shows whats in the sourcemap. And if vscode thinks it has found the real source file on disk, then it uses that. I think that's the correct thing to do most of the time.

change create-react-app to "not do whatever transformations it's doing on this file, since they seem to only be formatting-related"

I think this would be the best fix, but I don't know where to start looking to see what it's actually doing here.

[justingrant]

@raiskila @roblourens - I filed a new issue #6296 to simplify the repro by removing VSCode from the repro. Hopefully this will make it easier for non-VSCode users to reproduce and fix the problem!

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[justingrant]

Not stale!

[ziriax]

Hitting the same problem here...

[thiago-qat]

facing the same issue here

[bflorat]

same here !