CRA2 recommended config hits random break points in VS Code

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes

npm --version
6.4.1
yarn --version
1.10.1

Which terms did you search for in User Guide?

"vs code" debugger breakpoints

Environment

  System:
    OS: macOS 10.14
    CPU: x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
  Binaries:
    Node: 10.10.0 - ~/.nvm/versions/node/v10.10.0/bin/node
    Yarn: 1.10.1 - ~/.nvm/versions/node/v10.10.0/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.10.0/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Safari: 12.0
  npmPackages:
    react: ^16.5.2 => 16.5.2 
    react-dom: ^16.5.2 => 16.5.2 
    react-scripts: 2.0.4 => 2.0.4 
  npmGlobalPackages:
    create-react-app: 2.0.2

Steps to Reproduce

Install VS Code 1.27.2 or 1.26.1
npx create-react-app debug-cra2
Add recommended Debug CRA Tests snippet to .vscode/launch.json
Add the snippet below to src/App.test.js
Set breakpoint on line 13 console.log({ foo })
Hit F5 and debug

Snippet for App.test.js

it('should find the breakpoint', () => {
  const foo = 'bar'
  console.log({ foo })
  expect(foo).toBe('bar')
})

it('should find the other breakpoint', () => {
  const foo = 'bar'
  console.log({ foo })
  expect(foo).toBe('bar')
})

Expected Behavior

Execution stops on line 13

Actual Behavior

Execution stops on line 6 or 7, it's inconsistent.

Reproducible Demo

https://github.com/ryanwmarsh/debug-cra2

For added information...

Using the Chrome inspector works fine.

Steps to reproduce:

Add the snippet below to package.json
Add debugger statement to line 13
npm run test:debug
Open chrome://inspect
Resume script execution
Observe that execution pauses on debugger

package.json snippet:

"scripts": {
 "test:debug": "react-scripts --inspect-brk test --no-cache --runInBand --env=jsdom"
}

I'm not sure if this is a VS Code bug or a problem with CRA's recommended launch.json settings.

@auchenberg

@auchenberg Can you please look at this?

@ryancogswell

This sounds like a sourcemapping problem that causing the breakpoint to be set on the wrong line. Adding debugger should also make the VS Code debugger break. I'll add debugging this to my backlog.

Question @ryancogswell Can you set breakpoints with Chrome DevTools using their Node.js debugging? Breakpoint from the gutter.

I'm not a VSCode user but I was troubleshooting this issue two weeks ago for devs on my team (on an ejected create-react-app build) and I couldn't understand why it worked with react-scripts (prior to v2 release) but didn't on mine. I configured the launch.json like this for CRA (which worked):

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "Debug Jest (CRA)",
        "type": "node",
        "request": "launch",
        "runtimeExecutable": "react-scripts",
        "runtimeArgs": [
          "--inspect-brk"
        ],
        "args": [
          "test",
          "--runInBand",
          "--no-cache",
          "--watch",
          "--env=jsdom",
          "--coverage"
        ],
        "env": {
          "NODE_ENV": "test"
        },
        "cwd": "${workspaceRoot}",
        "protocol": "inspector",
        "console":"integratedTerminal",
        "internalConsoleOptions":"neverOpen"
      }]
}

But on my build it didn't work. After a lot of side-trails and meandering through VSCode and Jest issue threads I finally got it working by downgrading my project's version of Jest from 23.4.x to 22.2.0, and it started working.

@arizonatribe

@arizonatribe Thank you for taking the time to figure this out and share it. I lost two days trying to fix this and the one thing I failed to try is downgrading Jest.

@auchenberg Do you think I should open an issue with Jest?

tl;dr: a workaround is that breakpoints set after launching work.

I can repro this, I tried downgrading jest in the test repo, but it doesn't make a difference for me? Could one of you share a test repo where it does work with jest downgraded? Or if it's easier just set "trace": true in your launch config, run it again, and share the log file.

Here's the problem: In a transpiling scenario you can use the outFiles parameter to point vscode towards the output sourcemaps so it can preload them and resolve your breakpoints to their real locations. But in this scenario, the sourcemaps are generated in memory and don't exist on disk.

So you set a breakpoint in a .js file. VS Code doesn't know whether it's a bp in a script with no sourcemaps, or a transpiled script that will have sourcemaps at runtime. Since it's a .js file, we guess and set breakpoints for that path and line. Anyone using .ts or something else won't see an issue.

Then, jest loads the transpiled script and gives it the same path as the file on disk. It's a match, and your breakpoint hits. But the line numbers don't match between the two scripts, so you've stopped on the wrong line. At the same time, vscode has loaded the sourcemap so any breakpoints you set at this point will bind correctly.

If this is really new in Jest then they might have changed how they name the loaded scripts. If they can name them differently from the source files on disk, that would fix this. Maybe we should provide an option to disable this optimistic bp placement but it should "just work"...

But this scenario where sourcemaps can't be preloaded from disk has always been imperfect in vscode. We would still have a race to load the sourcemap and set the BP before the line of code with the BP executes. Chrome gives us a way to break every time a script loads, giving us a chance to catch up and load sourcemaps. Node doesn't support that unfortunately. We've experimented with guessing the name of the script at runtime, setting a BP for line 1, then checking whether it has sourcemaps. That would help in this scenario but is complex and relies on the name of the script at runtime matching the path on disk.

Yikes sorry for the wall of text...

I'm not sure I can share the code repo without permission, but I'll check and see if it's okay to share the logs.

I forgot one other thing I did was set reatainLines to true and sourceMaps to "inline" in the Babel config (but only for the Babel test env)

reatainLines to true

That sounds extremely likely to help, how do you do that? I'm not clear on how you override config in a CRA app

I don't believe that part can be customized unless you eject . When the app is ejected, the babelrc: false and configFile: false code are removed.

I know ejecting is not a solution (maintaining an ejected create-react-app based build eats up a good portion of my time and makes me develop an irrational dislike for jest, webpack and and the whole ecosystem of plugin/loader authors that can never stay in-sync), but you might be able to verify locally whether it works with a Jest downgrade to v22 and/or by setting that prop locally in the node_modules/react-scripts/config/jest/babelTransform.js.

const babelJest = require('babel-jest');

module.exports = babelJest.createTransformer({
  presets: [require.resolve('babel-preset-react-app')],
  retainLines: true,
  sourceMaps: 'inline',
  babelrc: false,
  configFile: false,
});

Then you should be able to re-launch the test script in VSCode to see if it's hitting those breakpoints correctly or not.

If that setting is the trick to getting it working (and especially if it works with Jest v23) maybe they'll accept a PR for changing the babelTransform.js file.

Ok I was able to create a project with create-react-app@1, and I do see that it sets retainLines in node_modules/babel-jest/build/index.js. I think that bringing that back is the best fix. I'll try to do a PR for babel-jest.

It seems that retainLines was removed because of a Babel bug that gives bad output with that option. jestjs/jest#5326 The upstream bug has been open for awhile: babel/babel#7275

I think there are a couple things vscode could do to make this scenario work better but they are not great and I don't want to add more options or modes.

At the moment, setting retainLines: true in node_modules/react-scripts/config/jest/babelTransform.js is a good local workaround, assuming your code doesn't trigger the babel bug.

I'd appreciate any other suggestions, in the meantime I'll think about what vscode can do here...

Not sure if this is the right thing to do here but I submitted babel/babel#8868

I have no idea what I'm doing.

Adding unnecessary comment to get stalebot to re-open this issue.

We will be releasing a new version including the change made in #5060 shortly. I hope this may improve some of these issues you're experiencing.

@ianschmitz

@ianschmitz - unfortunately I don't think this will help because I've already tested every possible devtool option (see #6296 (comment)) and none of them fixed the problem described in #6296 where the webpack sourcemap content doesn't match the original source files in node_modules.

But regardless I'll definitely try the new release to see if some other commit helps.

"env": { "CI": true },
"disableOptimisticBPs": true

Has solved the problem for me !

@johnrazeur

@johnrazeur You put those in .vscode/launch.json?

@ryanwmarsh yes

@johnrazeur

@johnrazeur I just tested it and created a PR. Thank you!

What does "env": { "CI": "true" }, do?

This works great. Is this where we spam the PR with 👍 @ryanwmarsh

"env": { "CI": true },
"disableOptimisticBPs": true
Has solved the problem for me !

Thanks for the solution!
For me disableOptimisticBPs: true alone did the trick.

For whoever is having issues debugging Webdriver.IO, the "disableOptimisticBPs": true in the launch file does the trick. Example project here.

Navigation Menu

Repository navigation

CRA2 recommended config hits random break points in VS Code #5319

Is this a bug report?

Did you try recovering your dependencies?

Which terms did you search for in User Guide?

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Reproducible Demo

37 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CRA2 recommended config hits random break points in VS Code #5319

Description

Is this a bug report?

Did you try recovering your dependencies?

Which terms did you search for in User Guide?

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Reproducible Demo

Activity

ryan-mars commented on Oct 5, 2018

gaearon commented on Oct 5, 2018

auchenberg commented on Oct 6, 2018

arizonatribe commented on Oct 9, 2018

ryan-mars commented on Oct 9, 2018

roblourens commented on Oct 9, 2018

arizonatribe commented on Oct 10, 2018

roblourens commented on Oct 10, 2018

arizonatribe commented on Oct 10, 2018

roblourens commented on Oct 10, 2018

roblourens commented on Oct 10, 2018

ryan-mars commented on Oct 13, 2018

37 remaining items

justingrant commented on Feb 7, 2019

ianschmitz commented on Feb 10, 2019

justingrant commented on Feb 10, 2019

johnrazeur commented on Feb 21, 2019

ryan-mars commented on Feb 21, 2019

johnrazeur commented on Feb 21, 2019

ryan-mars commented on Feb 21, 2019

roblourens commented on Feb 22, 2019

codenamekt commented on Mar 12, 2019

danielkatz commented on Mar 14, 2019

mvgiacomello commented on Jul 6, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions