vscode: Attachment fails on Node 8
- VSCode Version: 1.47
- OS Version: OSX 10.15.5
Steps to Reproduce:
1.Run app and first thing I notice is console.log doesn’t show their usual messages. In my app usually 2 messages show up, “Express running on port 3000”, and “Settings updated…” They no longer appear.
2.Run app and I notice that all the break points I set turned to hollow circles, and they do not stop when the code is executed. You can see the screen shot where the break point has turned to a hollow circle. Hovering over the break point says, “Unbound breakpoint”.
3. These issues only started after I was automatically updated to 1.47 today.
Does this issue occur when all extensions are disabled?: Yes/No (don’t know, I tried running this and got “zsh: command not found: code”
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 21 (11 by maintainers)
Commits related to this issue
- fix: connection error on node 8, check sanity in 8 in ci Fixes https://github.com/microsoft/vscode/issues/102166 — committed to microsoft/vscode-js-debug by connor4312 4 years ago
- fix: connection error on node 8, check sanity in 8 in ci Fixes https://github.com/microsoft/vscode/issues/102166 — committed to microsoft/vscode-js-debug by connor4312 4 years ago
Fixed in the linked commit.
How can you fix your debugging? Either:
debug.javascript.usePreview: falseto temporarily use the old debugger, at least until (3) happensWhat happened? We used
Promise.finallyin some timeout-related code. This was undefined on Node 8, and crashes the watchdog process responsible for setting up communication between your program and VS Code.Why did it happen? We’re aware that some code will run in the user’s Node version, and we have our TypeScript options set for that – targeting ES2017 in our lib and target parameters, which is advertised to map to Node 8. However, Promise.finally was present in those typings, even though Node 8 didn’t have it.
How can we prevent this? Our test suite runs against Node 12 – previous version of Node don’t have some features that we (optionally) need to build and test new features. I’ve now added an additional ‘minspec’ build that runs select tests against Node 8 to ensure sanity https://dev.azure.com/vscode/VS Code debug adapters/_build/results?buildId=48413&view=logs&j=a8e58cb5-ff8c-58f5-08fa-0c710542c7b6
Longer term we will need a policy around what versions of Node we support. In js-debug we dropped support for versions <7, since they run an entirely different protocol. Going forward, what should we do – match Node LTS? LTS + 1 year? Or usage based.
A fix for this issue has now been released in VS Code 1.47.2. If you previously had to opt-out of the new debugger, you should be safe to turn it back on. Thanks again for the report!
We have several old node modules that we rely on that won’t run in anything newer than 8. We know that is a problem, and we will have to look for some alternatives at some point, but that’s the only thing keeping us in Node 8 for now. Thanks, though and this just gives us another reason to start looking more quickly for an alternative.
Ahh, that’s the key! I was able to reproduce running that version of Node as well. I should be able to have a fix for it shortly.
Also, just in case you didn’t know, Node 8 is EOL as of April. If there’s nothing keeping you there, updating to Node 14 gets you lots of nice new features and performance 🙂
Thank you @dlgenterprises , having
"debug.javascript.usePreview": falsesetting helped perfectly!I do have Bitdefender installed, but I just turned that off and tried it again and that didn’t make a difference. To my knowledge there have been no other updates installed today except VS Code 1.47, it was working fine yesterday. BTW, setting debug.javascript.usePreview: false seems to fix the problem.