I am writing a test suite for my VS Code extension using vscode-extension-tester, and my tests need to involve the opening of a workspace file. I need the workspace file to be opened as soon as the browser is launched, in order for my subsequent tests to pass.
I am able to open the workspace file as a separate test; however, I was wondering if there's any setting that allows the workspace to be opened before any test is launched. Is there a way to do this with vscode-extension-tester?
The way I handle this is through my launch configuration (launch.json).
Using an extensionHost type launch configuration you can pass a workspace file. This means that the code instance will open with the given workspace active whenever you execute it.
For example:
{
"version": "0.2.0",
"configurations": [
{
"name": "Run Extension",
"type": "extensionHost",
"request": "launch",
"args": [
"${workspaceFolder}/src/test/workspace/workspace.code-workspace",
"--extensionDevelopmentPath=${workspaceFolder}"
],
"outFiles": [
"${workspaceFolder}/dist/**/*.js"
],
"preLaunchTask": "${defaultBuildTask}"
},
{
"name": "Extension Tests",
"type": "extensionHost",
"request": "launch",
"args": [
"${workspaceFolder}/src/test/workspace/workspace.code-workspace",
"--extensionDevelopmentPath=${workspaceFolder}",
"--extensionTestsPath=${workspaceFolder}/out/test/suite/index"
],
"outFiles": [
"${workspaceFolder}/out/**/*.js",
"${workspaceFolder}/dist/**/*.js"
],
"preLaunchTask": "tasks: watch-tests"
}
]
}
Note the path to workspace.code-workspace that is specified as an arg to both of these launch configs.
You will likely already have launch configs like this for running and testing your extension if you used Yo Code to generate your extension at the start of development.
So in summary:
Create your workspace
Store the workspace file accordingly (for me it made sense to be within ./src/test)
Configure extensionHost type launch configs with a path to the workspace file given as an arg in the args array.
I am a new user to vscode. I viewed Lukas Lamm's video of vscode Fortran, but I am still having problems:
can't build code
can't launch code for debug
I have a makefile which requires some environment variable definitions for, say, the compiler type, $COMPILER. I have included the makefile extension but when I do a 'make all' there, the environment variables remain undefined. I have no problem doing a 'make all' in the vscode terminal window. How do I configure the Makefile extension to parse these environment variables?
I did write a launch.json file to run my code - I think exactly the way Luke Lamm indicated in his video. My code requires an input file:
heatx.exe < heatx.inp
but it never finds it - it just hangs at the read statement (It finds heatx.exe fine). Below is my launch.json script:
{
"version": "0.2.0",
"configurations": [
{
"name": "Run GDB",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/heatx.exe",
"args": [
"<",
"${workspaceFolder}/heatx.inp"
],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"externalConsole": false,
"MIMode": "lldb",
"preLaunchTask": "make"
}
]
}
I checked other vscode questions about input files and this was exactly the solution they suggested.
I don't think this has anything to do with makefiles so you should probably remove the makefile tag.
I'm no expert at vscode, but I don't think this can work:
"program": "${workspaceRoot}/heatx.exe",
"args": [
"<",
"${workspaceFolder}/heatx.inp"
],
IO redirection (handling of <) is a feature of the shell. Here you're not invoking a shell, you're invoking heatx.exe, so there's nothing to handle the redirection. This basically runs your program heatx.exe with two arguments: a literal < and the file .../heatx.inp. But your program is reading from stdin, and nothing is there.
You either need to rework your program so it takes a filename and opens that file and reads from it, so you can run heatx.exe heatx.inp, then you can use:
"program": "${workspaceRoot}/heatx.exe",
"args": [
"${workspaceFolder}/heatx.inp"
],
Or you have to run a shell and tell it to run your program in a shell script, like this:
"program": "/bin/sh",
"args": [
"-c",
"${workspaceRoot}/heatx.exe < ${workspaceFolder}/heatx.inp"
],
Note! This will work on any POSIX system like Linux or MacOS. You don't say what system you're working on but this likely won't work on Windows unless you have various things installed and set up, and you might need to use a different path for a shell. Or I guess you could try to write it with cmd.exe but all this Windows stuff is beyond me.
Hello I'm working with pipenv which have a differetn path for every developer, but I want to have the same launch setting for all. The problem is that the program is not the python is a custom executable with is under the virtual environment bin folder.
Here is my current launch.json
{
"name": "Python: TEST",
"type": "python",
"request": "launch",
"stopOnEntry": false,
"console": "integratedTerminal",
"program": "${env:HOME}/.local/share/virtualenvs/venv-PbRe8Lzd/bin/<program>",
"args": [
...
],
"cwd": "${workspaceRoot}",
}
And for me works OK becaouse my is under "venv-PbRe8Lzd/bin/" but for the other developers that have different venv folder no. Any Idea on how to do this generic for all?
I think better not to sync .vscode folder at all. But anyway it's possible to put interpreter path into another file ".vscode/settings.json".
Delete "program" from launch.json.
Install the Python extension for Visual Studio Code https://github.com/Microsoft/vscode-python (probably it's already installed)
Press Ctrl+Shift+P
Search "Python: Select Interpreter"
Select pipenv interpreter path
or
Create/modify file ".vscode/settings.json"
{
"python.pythonPath": "${env:HOME}/.local/share/virtualenvs/venv-PbRe8Lzd/bin/python"
}
I am trying to use VSCode to debug a node app I am running.
I launch the app in a separate terminal and then use the attach to process configuration to hook into it.
The attaching works correctly and I get a side panel that says 'loaded scripts' with the files in my project. If I click on one of those and set breakpoints there it will work correctly.
If I set a breakpoint on a file I open through the VSCode editor the breakpoint is greyed out and when I hover over it will say 'Breakpoint set but not yet bound'.
How can I make it so that the breakpoints I set on the code are bound?
Try this configuration in your launch file:
{
"name": "Attach to Process",
"type": "node",
"protocol": "inspector",
"request": "attach",
"stopOnEntry": false,
"port": 5858,
"localRoot": "${workspaceRoot}",
"remoteRoot": "/somepath/myprojectroot",
"sourceMaps": true
}
Make sure the remoteRoot is correct path, otherwise it won't know where to look for the source files.
On the VSCode settings search for 'debug javascript use preview', and then disable it. It should now bound all breakpoints.
I had a similar problem, I fixed it by appending /src to the "webRoot" path.
Here is an Example to Demonstrate What I Did:
Originally my "webRoot" property read:
"webRoot": "${workspaceFolder}"
Now my webRoot path reads:
"webRoot": "${workspaceFolder}/src",
Here is my ./.vscode/launch.json reads:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome",
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}/src",
"trace": true
}
]
}
I had this issue with VSCode 1.52.1, the fix that worked for me was:
Disable debug.javascript.usePreview via Code > Preferences > Settings
Add "localRoot": "${workspaceFolder}/" to launch.json
Add "remoteRoot": "${workspaceFolder}/" to launch.json
The plain truth is that VSCode 1.20 does not allow you to hit breakpoints.
I tried 1.21 too, it also does not let you do it.
I went back to 1.18 and it works just as expected, no problem.
I faced the same issue...
After i try a lot of launch config combinations, i found the correctly.
{
"type": "node",
"request": "attach",
"name": "Attach Program",
"protocol": "inspector",
"restart": true,
"skipFiles": [
"<node_internals>/**"
],
"localRoot": "${workspaceFolder}",
"remoteRoot": "/",
}
Ps: I'm launch node script with nodemon using the --inspect parameter (that allow debugger to attach node).
I faced this issue as recently as yesterday after upgrading to VSCode 1.52.1. Debugger which was previously working fine suddenly started showing "Unbound Breakpoint". This was happening for all the breakpoints I was trying to set regardless of the place/file/line in code. I then had to add the "localRoot" property and make it point to my source code folder for it to start working again. Hope this helps. My launch.json configuration now looks like this
{
"name": "Attach by Process ID",
"processId": "${command:PickProcess}",
"request": "attach",
"skipFiles": [
"<node_internals>/**"
],
"localRoot": "${workspaceFolder}/Source",
"type": "pwa-node"
}
For me, just adding "localRoot": "${workspaceFolder}" to my default launch.json Configuration did the trick.
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}/bin/www",
"localRoot": "${workspaceFolder}"
}
I'm late to the party but wanted to share what was causing my "Unbound Breakpoint" errors.
I have file A and B. File A called into File B (and was required at the top of File A). File A's breakpoints were working perfectly. File B's sometimes let me hit them but I wasn't getting the full debugging experience if it worked at all.
I finally realized the require statement at the top of File A had different casing than the actual folder structure. It was requireing /path/to/file, where it should have been /Path/To/File.
I fixed the path casing and the breakpoints in File B starting working again.
The very first thing you should check is the entry point - the first line of code that gets executed. If that one can bound a breakpoint, then you know your other breakpoints are unbound because something between the time your other breakpoints are met is pre-empted by an error introduced. Your code is not reachable in that case and the IDE can detect that your module is not loaded at all.
If all this doesnt work - consider starting your vsCode in the correct folder
(the root directory, e.g. C:\Users\user\programming\RandomApp).
This is also why some people need to specify "/src" to their workspace variable (just a wild guess) and others dont.
Start it in the correct Folder and you dont need the /src parts in the launch.json file.
for me this launch.json works with vscode version 1.59.1
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8100",
"webRoot": "${workspaceFolder}"
}
]
}
I have a TypeScript project, which suddenly didn't hit breakpoints anymore. In my case I had to move the project folder out of my iCloud Drive folder. There were other indicators that this path wasn’t ok, like missing git gutter indicators, as well. Here is my debug launch config. Breakpoints placed in app.ts are being hit.
{
"type": "node",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/src/app.ts",
"sourceMaps": true,
"protocol": "inspector",
"cwd": "${workspaceFolder}",
"outFiles": [
"${workspaceFolder}/dist/**/*.js"
]
}
I'm using this configuration for debugging a TypeScript project:
{
"name": "Debug API",
"request": "attach",
"skipFiles": [
"<node_internals>/**"
],
"type": "pwa-node",
"sourceMaps": true,
"outFiles": [
"${workspaceFolder}/**/*.js",
"!**/node_modules/**"
]
},
outFiles did the trick and bound my breakpoints (VS Code 1.51.1).
I am running Docker Compose with the VSCode debugger and in my case, some of the breakpoints I set show unbounded and some show as bounded, even after trying the solutions above.
It seems the unbounded ones are outside of functions (on require or variable initialization statements for example).
I can only assume this is because the debugger attach runs after the docker containers have started (and hence these breakpoints are unreachable).
#alkasai has the correct answer.
But, it also matters which source code folder was added to your workspace. My repository structure is as such: C:\git\parent_folder\child_folder\src
My breakpoints were not working, so long as 'parent_folder' was the folder added to my workspace and my 'webRoot' entry looked like this:
"webRoot": "${workspaceRoot}",
But, if I added '/child_folder' to 'webRoot' (e.g. "webRoot": "${workspaceRoot}/child_folder"), the breakpoints worked.
However, if I removed 'parent_folder' from my VS Code workspace, and instead added 'child_folder' to the workspace (thus changing the underlying value of the '${workspaceRoot}' variable value), the original entry (without the '/child_folder' subfolder reference) caused the breakpoints to be activated.
For me the problem was that I forgot to set "sourceMap": true in my tsconfig.json file.
To hit breakpoints you need to compile in debug mode.
So when compiling the code using your tasks.json have debug flags enabled in your command attribute. C++ example :
{
"version": "2.0.0",
"tasks": [
{
"label": "Compile Test",
"type": "shell",
"command": "g++ -g test.cpp",
"presentation": {
"echo": true,
"reveal": "always",
"focus": false,
"panel": "shared",
"showReuseMessage": true,
"clear": true
},
"group": "build",
}
]
}
I am talking about the -g flag in the "command": "g++ -g test.cpp",