Describe the bug
When executing my React app (created with CRA), the breakpoints I am setting are unbound and do not get hit in VS Code.
However, adding debugger statements to the code will drop me into VS code and allow me to step through the process. One thing I have noticed is that when I drop to code on a debugger statement I am in a compiled main.chunk.js file rather than my expected component file.
I use a Windows machine to a remote Linux box using the SSH remote VS code extension. I run npm start on the command line to start the React application and then F5 to run my debugger process.
My launch configuration is below:
{
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://${env:SWA_DEV_SYSTEM_IP}:3000",
"webRoot": "${workspaceFolder}/src",
"trace": true
}
]
}
I have log files attached. v0 is without the debugger statement, v1 is with it.
To Reproduce
I was able to replicate this on a split new CRA app.
create-react-app to create a new base application.npm start the applicationlaunch.json has the correct IP address for your app server and is mapped to the /src directory.Log File
vscode-debugadapter-0.json.gz
vscode-debugadapter-1.json.gz
VS Code Version: 1.49.2 (user setup)
Happy to provide any more detail as required.
It looks like we're failing to load the sourcemap for the bundle:
Could not read source map for http://192.168.56.102:3000/static/js/bundle.js: Unexpected 400 response from http://192.168.56.102:3000/static/js/bundle.js.map
I'm guessing perhaps that since it's on a different IP address, maybe the Host check is failing it? You can try setting DANGEROUSLY_DISABLE_HOST_CHECK to see if that's the cause.
Thanks for the advice but that's still not resolved the issue.
I have added an .env.development.local file with the following content:
HOST=192.168.56.102
DANGEROUSLY_DISABLE_HOST_CHECK=true
When starting the npm start process I now get:
`You can now view sd-client in the browser.
http://192.168.56.102:3000`
Note that "localhost" is now gone. However I still get the same problem, and the HTTP 400 errors for the source maps still show as well.
Unexpected 400 response from http://192.168.56.102:3000/static/js/bundle.js.map
I have also installed the latest nightly build of the extension just to have the latest code but still having the same issues. Most recent log file attached below.
Anything else I can do to help diagnose this then the better.
With create-react-app using Babel is there any other config I should be doing in launch.json etc?
Hm, okay. I've made a build of the extension that will also log the response body (and this will be available in the nightly as well.) Maybe that will give us some more hints.
Download it here https://memes.peet.io/img/781-js-debug-nightly.vsix and then install it via the "install from vsix" command. This is a nightly build, so make sure you still have the stable js-debug disabled.
That file is telling me that it's not compatible with VSCode 1.49.2.
However I think I know what the problem is...
I did a wget -v http://192.168.56.102:3000/static/js/bundle.js from the command line and got the same 400 error, despite the fact that accessing the same file from the Windows box works OK (HTTP 200).
The problem here is that the IP address was not being excluded in my Linux machines $no_proxy value. I have now added the IP to $no_proxy and wget works fine with no error.
Unfortunately I cannot seem to get the debugger to pick up that no_proxy change.
Okay, thanks for the info! Unfortunately I'm not an expert in the remote scenario for that. @roblourens may be able to provide some advice since I see he commented on similar issues in remote before.
I will go ahead and close this issue since there does not appear to be a problem with js-debug. Thanks for the report!
I don't actually know a lot about it. Is that an environment variable? Did you totally restart vscode after changing it? Have you set any of the "proxy" settings in vscode?
Seems that a server reboot means that the process is now picking up the no_proxy env variable I set in .bashrc.
The debugger is now picking things up correctly!
Thank you @connor4312 and @roblourens for the advice, appreciate it!!
Oh yes, restarting the server is necessary. I missed that this was remote.