Possible to blackbox scripts coming from node_modules?
See original GitHub issueI have long stack traces, I tried skipFiles without much luck. Is there a glob that can be passed in to filter out libraries in node_modules like react etc?
I passed in “node_modules” but that didn’t work (I still get library files in the call stack), I will see if I can make reproducible steps
I tried following the advice of https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_skipping-uninteresting-code-node-chrome which says to use ${workspaceFolder}/node_modules/**/*.js
I was looking for documentation on how to properly do this but couldn’t find any so I opened https://github.com/microsoft/vscode-js-debug/issues/471
Version v2020.5.1217
VSCode Version Version: 1.46.0-insider (system setup)
Screenshot
Below you can see on the right I’ve set node_modules in skipFiles
.
but on the call stack on the left i still have all of the express files.
Same but with smartStep enabled
Steps to reproduce the above
- Clone https://github.com/jasonwilliams/nextjs9-typescript-server-vscode-example
- npm install
- add
${workspaceFolder}/node_modules/**/*.js
to .vscode/launch.json similar to the screenshot - in VSCode “launch server” debugger
- add a breakpoint in server/index.ts (line 16
return app.render
) - “launch chrome” in debugger tab
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:15 (15 by maintainers)
Top GitHub Comments
Thanks for the emailed logs!
The problem was because the script skipping logic only used absolute paths for files on disk that were identical to ones Node loaded. Jest does some ‘weird stuff’ in general and this was case for a couple of your files (I actually see the same path getting loaded twice, we ignore the duplicate load but the second one might have been the real file). In f34d43e I changed our logic to use the hypothesized disk path for setting up script skipping, when present, whether or not the contents match. I think this is a better approach since this behavior would have caused the same inconsistencies when using things like ts-node or @babel/register.
cc @roblourens who wrote this code – let me know if you see any problems with this.
If we go this change we can also make skipping initialization synchronous since we no longer do heavy work in this code path.
I can’t reproduce this at the moment, so will let you know if i see it again