I am quite new to Polymer and I would like to be able to debug projects straight from one IDE. I mean, instead of using Chrome debugger, I would prefer debug from Visual Studio Code or Sublime or Atom or another tool (kindly, there is no interest in this question to compare the IDEs available. I just want some way to debug from any IDE).
All subjects I have read so far didn't me drive to any real tutorial which could help me. The only one I found I couldn't make it run.
I followed https://medium.com/collaborne-engineering/debug-polymer-tests-with-vs-code-7646d66d0608 and when I try Run WCT I get Attribute 'program' doesn't exist.
My launch.json is
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Run wct",
"program": "${workspaceFolder}\\my-company-component.html",
"args": [
"-p",
"--skip-plugin", "local",
"--plugin", "none",
"--webserver-port", "2000",
"--expanded",
"--simpleOutput", "${workspaceFolder}"
]
},
{
"type": "chrome",
"request": "launch",
"name": "Run chrome for wct",
"url": "http://localhost:2000/components/my-company-component/generated-index.html",
"webRoot": "${workspaceRoot}",
"userDataDir": "${workspaceRoot}/.vscode/chrome"
}
]
}
Today, I have been using gulp to start a local server and then debug using Chrome but, in case it is possible use an IDE + some extension/plugin I would prefer.
program should be either 'wct' if you installed it with -g or
"${workspaceRoot}/node_modules/.bin/wct" if you installed it locally using npm.
That should solve your error, I did not get the other parts to work still though..
Well, after several tentatives and searching for while, I assume that the only way to debug is by using Chrome. I mean, I didn't find any efficient way to debug using Visual Studio Code, Atom or other IDE. I will consider https://github.com/Polymer/polymer/issues/3635 as an answer to my question.
Related
I'm currently coding in Haxe with Heaps using Visual Studio Code. The latter has recently updated to version 1.56 which is now giving my a strange problem I can't manage to fix. Before the update, I was able to click Run and Debug using Hashlink in order to open the window of my game. After the update, when I Run and Debug it no longer opens the window, despite the compile.hxml and launch.json being exactly the same as before:
compile.hxml:
-cp src
-lib heaps
-lib hlsdl
-hl main.hl
-main Main
.json
"version": "0.2.0",
"configurations": [
{
"name": "HashLink (launch)",
"request": "launch",
"type": "hl",
"cwd": "${workspaceFolder}",
"preLaunchTask": {
"type": "haxe",
"args": "active configuration"
}
},
{
"name": "HashLink (attach)",
"request": "attach",
"port": 6112,
"type": "hl",
"cwd": "${workspaceFolder}",
"preLaunchTask": {
"type": "haxe",
"args": "active configuration"
}
}
]
Is anyone experiencing a similar problem?
Update: hashlink-debugger 1.1.2 was released, which should fix the problem.
It's a known issue:
HL debugger no longer works in latest vscode #97
You can downgrade to the previous VSCode release or subscribe to the issue and wait for the hashlink-debugger update.
i am new to Visual studio Code. I followed this tutorial to set up a Bazel build configuration in Visual studio code (I use Windows 10).
I created a simple task.json
{
"version": "2.0.0",
"tasks": [
{
"label": "Build Example (Debug)",
"type": "shell",
"command": "bazel build //main:hello-world -c dbg",
"windows": {
"command": "bazel build //main:hello-world --experimental_enable_runfiles -c dbg"
},
"osx": {
"command": "bazel build //main:hello-world -c dbg --spawn_strategy=standalone",
},
"group": {
"kind": "build",
"isDefault": true
},
}
]
}
and launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Example",
"type": "cppvsdbg",
"request": "launch",
"args": [],
"stopAtEntry": false,
"preLaunchTask": "Build Example (Debug)",
"cwd": "${workspaceFolder}/bazel-out/x64_windows-dbg/bin/example.exe.runfiles/__main__/",
"program": "${workspaceFolder}/bazel-out/x64_windows-dbg/bin/main/hello-world.exe",
"externalConsole": false,
"windows": {
"type": "cppdbg",
"type": "cppvsdbg",
"cwd": "${workspaceFolder}/bazel-out/x64_windows-dbg/bin",
"program": "${workspaceFolder}/bazel-out/x64_windows-dbg/bin/main/hello-world.exe",
},
},
}
]
}
In this way with run-> start debugging, I am able to debug and stop to breakpoins within the .cpp code of my project.
However, I read here, that is also possible to use the Starlark debugger to debug the .bzl files and Starlark rules.
According to the instructions in the same page I should be able to do this "by right-clicking a build target in the Bazel Build Targets view and selecting "Build Target with Starlark Debugger"". Unfortunately i can't see this option in my Bazel Build Targets view windows:
The Bazel Build Targets view is empty. and if i right click i can't see the "Build Target with Starlark Debugger" option. According to this link i should be able to see my targets listed below Bazel Build Targets view. I guess i am missing something in the configuration of the project or maybe some starlack extension?
Thanks for any help.
Bazel build targets does not work for me on windows either. When I run it, the extension outputs some error about bazel query. I haven't been on windows recently enough to remember the exact message, but I believe it is something along the lines of what is documented in this open issue.
Looks like there is a pull request open to solve it but no one has reviewed it yet. Best bet might be to weigh in over on either one of those after checking your extension output error log to see if it matches what is documented in there. Alternatively, you can check out the Clion with Bazel plugin, I have not tried that on windows yet though.
I'm running Ubuntu 18.04 and just installed VSCode 1.35.1. I installed the Java packages, created a project from maven, and then tried to run the unit tests. The tests run, but none of the print messages are showing anywhere.
My launch.json looks like this,
{
"version": "0.2.0",
"configurations": [
{
"type": "java",
"name": "Debug (Launch) - Current File",
"request": "launch",
"mainClass": "${file}",
"console": "integratedTerminal"
},
{
"type": "java",
"name": "Debug (Launch)-App<ttt>",
"request": "launch",
"mainClass": "exercises.App",
"projectName": "ttt",
"console": "integratedTerminal"
}
]
}
When I run with F5 or Ctrl-F5, it always runs the main App. When I go to my test file and click on the Run|Debug links, the tests run and generate reports, but I don't see any of the print messages I put in.
What do I need to setup differently?
The Test Output is in the Java Test Runner Output.
You can highlight it with the "Java: Show Test Output" command in the F1 menu
With VSCode 1.64 (Jan. 2022), you won't have to look for that view anymore when launching a debug session.
It allows for VS Code to automatically switch to test explorer when users click 'run tests'.
See issue 140596 / issue 135999, solved by commit a47b55c
You now have the options:
NeverOpen = 'neverOpen',
OpenOnTestStart = 'openOnTestStart',
OpenOnTestFailure = 'openOnTestFailure',
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",
Since Visual Studio Code was created using Electron, I'm guessing that launch.json might be configured to properly launch an app using Electron. But I've not figured out how to do it yet.
Also since Electron is based on io.js, itself based on Node.js, I'm thinking maybe... it can be done, but haven't found the magic yet.
Tried something along these lines... snippet from launch.json:
"configurations": [
{
// Name of configuration; appears in the launch configuration drop down menu.
"name": "Launch Electron",
// Type of configuration. Possible values: "node", "mono".
"type": "node",
// Workspace relative or absolute path to the program.
"program": "Y:\\dev\\electron\\electron.exe",
// Automatically stop program after launch.
"stopOnEntry": false,
// Command line arguments passed to the program.
"args": ["CrawlSpace_Electron\\"],
// Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
"cwd": ".",
// Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
"runtimeExecutable": null,
// Environment variables passed to the program.
"env": { }
},
It does start Electron, but fails (window vanishes too fast to see exactly why).
Any thoughts?
If you specify electron.exe as the runtimeExecutable (as previously suggested) you can pass the main.js file as the program and it will work. Electron allows you to specify the directory OR the main.js file since that is pretty much what the package.json points to. Using the configuration below in my launch.json file, pressing F5 both launched Electron with my app and connected the debugger to the main process (eventually)...
{
"name": "Launch Electron",
"type": "node",
"program": "${workspaceRoot}/app/main.js", // ensure this is path to main.js file
"stopOnEntry": false,
"args": [],
"cwd": "${workspaceRoot}",
// as you have noted, this is also important:
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd"
},
My main.js file is in the app folder I normally would pass to Electron.
Yes, it could. Not only could VSCode launch Electron, it could also debug it.
Using node you can debug Electron's Main process, but with Debugger for Chrome you can also debug Electron's Renderer process. I wrote a blog post on this topic: http://code.matsu.io/1.
The current highest upvoted answer is a bit outdated.
You should use electron instead of electron-prebuilt. See http://electron.atom.io/blog/2016/08/16/npm-install-electron
You should use node_modules/.bin/electron to launch electron
On Windows it's electron.cmd, not electron.exe.
Here are two pre-configured projects: https://github.com/octref/vscode-electron-debug.
One configured to run electron/electron-quick-start
One modified from electron/electron-quick-start to use ES6 & Babel & Webpack.
Here is the launch.json for the first project. To run the target "Debug Renderer Process", you need to install Debugger for Chrome. But "Debug Main Process" works fine on vanilla VSCode.
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Main Process",
"type": "node",
"request": "launch",
"cwd": "${workspaceRoot}",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
// Use the following for Windows
// "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd",
"program": "${workspaceRoot}/main.js"
},
{
"name": "Debug Renderer Process",
"type": "chrome",
"request": "launch",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
// Use the following for Windows
// "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd",
"runtimeArgs": [
"${workspaceRoot}/main.js",
"--remote-debugging-port=9222"
],
"webRoot": "${workspaceRoot}"
}
]
}
In theory the following should work:
Specify the electron.exe as the "runtimeExecutable" (since it replaces the node runtime). The electron program ("CrawlSpace_Electron\") becomes the "program". VSCode automatically passes a "--debug-brk" or "--debug" to electron.exe.
In practice VSCode does not yet support this setup because the preview version of VSCode tries to verify that the "program" attribute is a file that exists on disk. But for electron the "program" must be a directory.
I have created a bug on our side and will make sure it’s fixed with the next release.
I know this is just 1 link but it's the answer everyone needs...
https://code.visualstudio.com/docs/editor/debugging#_launchjson-attributes
Here are the attributes documented for launch.json. Unsure if the list is currently complete, but it should at least help...
On OSX the path to electron is
"runtimeExecutable": "${workspaceRoot}/node_modules/electron-prebuilt/dist/Electron.app/Contents/MacOS/Electron",