-
Notifications
You must be signed in to change notification settings - Fork 282
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
skipFiles is not skipping node internals on Node 15 #862
Comments
Will this be available in the nightly release? |
Yep, in about an hour |
Sweet, thanks |
When stepping out of an async function in Node 16, is it expected that node_internals code shows up for about 500ms before display quickly shifts to non-skipped code? After this happens, my call stack looks like this: If not expected, I'll try to create a simple repro in a new issue. The top frame of the call stack is // Used by C++ to call all init() callbacks. Because some state can be setup
// from C++ there's no need to perform all the same operations as in
// emitInitScript.
function emitInitNative(asyncId, type, triggerAsyncId, resource) {
active_hooks.call_depth += 1;
resource = lookupPublicResource(resource);
// Use a single try/catch for all hooks to avoid setting up one per iteration.
try { |
That is a known bug in Node.js nodejs/node#36022 |
I'm not sure why a node bug would be causing vscode to show node internals when a setting has been explicitly set to ignore node internals. PS. this issue is unfixed for me. I can't recall whether it was fixed or not initially, but I can't step into async functions without getting into the node internals. All of my coworkers have switched to webstorm where they don't have this issue. |
Skipping files is implement by sending blackbox patterns to the runtime, which Node.js is not good about respecting in its internals. |
If blackbox patterns isn't being respected, that may mean vscode should be using a different mechanism of skipping node_internals. Webstorm has solved this problem, it may be worth consulting them. |
I believe an other option of skipping node internals is having the debugger only step into files that are present in the IDE. Opening files that aren't in the IDE isn't really beneficial in the majority of cases. |
As referenced in nodejs/node#36022 (comment), their approach is more of a workaround than a "solution". We could do something similar, but haven't yet.
js-debug asks the runtime to step in, but doesn't control where it stops. This isn't something we'd want to do in general since it's actually a pretty common scenario in some use cases. |
I'd personally be very happy with any band-aids and duct tape that prevents node_internals from being stepped into. As a user I wouldn't know any different
I'm definitely not experienced enough with edge cases where I'd want to step under the hood into frameworks, but if there was a setting (however it'd work) that said "step into files that aren't in this ide yes/no" I'd be very happy. Some functionality along the lines of 'auto continue if the file isn't in the ide', and additional functionality to break as soon as you reach files that do appear in the ide would be great. As it's a black box to me there are probably a bunch of edge cases to make this complicated/impossible, but the resulting functionality would be great. Not being able to step into async functions in javascript/typescript is a real productivity killer for me. |
I've opened a feature request for this here: #1085 |
Describe the bug
Debugging step into an async function still takes the IDE inside node internals.
To Reproduce
Steps to reproduce the behavior:
Log File
vscode-debugadapter-d741e5f7.json.gz
1.51.1
Additional context
Launch.json:
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"skipFiles": [
"<node_internals>//*.js",
"<node_internals>//",
"${workspaceFolder}/app/node_modules/**/.js"
],
"trace": true,
"name": "Debug via npm",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run-script",
"start:local-debug"
],
"port": 9229,
"cwd": "${workspaceFolder}/app"
}
]
}
Package.json:
{
"name": "batch",
"version": "1.0.0",
"description": "",
"main": "index.js",
"type": "module",
"scripts": {
"test": "echo "Error: no test specified" && exit 1",
"add": "npx ts-node ./src/addDocument.ts",
"get": "npx ts-node ./src/getDocument.ts",
"processing": "npx ts-node ./src/markDocumentAsProcessing.ts",
"tsnodedev": "npx ts-node-dev ./src/addDocument.ts",
"start:local-debug": "ts-node-dev --inspect --require dotenv-extended/config src/testDocumentClient"
},
"author": "",
"license": "ISC",
"dependencies": {
"aws-sdk": "^2.795.0",
"date-fns": "^2.16.1",
"date-fns-timezone": "^0.1.4"
},
"devDependencies": {
"@types/node": "^14.14.8",
"dotenv": "^8.2.0",
"dotenv-extended": "^2.9.0",
"ts-node": "^9.0.0",
"ts-node-dev": "^1.0.0",
"typescript": "^4.0.5"
}
}
TSConfig:
{
"compilerOptions": {
"module": "CommonJS",
"esModuleInterop": true,
"target": "ES2020",
"noImplicitAny": true,
"moduleResolution": "Node",
"sourceMap": true,
"outDir": "dist",
"baseUrl": ".",
"rootDir": "./",
"paths": {
"": [
"node_modules/"
]
}
},
"include": [
"src/**/*"
]
}
The text was updated successfully, but these errors were encountered: