Can I run and debug deno project in VSCode? - visual-studio-code

I'm new to both typescript and deno, also vscode.
Firstly, I tried it with vscode and failed, and then tried with IntelliJ.
I can run and debug simple .ts file in Intellij with deno plugin.
But I want to know how to do this in vscode(also installed deno plugin, https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno).
My settings are...
.vscode/settings.json
{
"deno.enable": true,
"deno.lint": true,
"deno.unstable": true
}
.vscode/launch.json
{
// 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": [
{
"request": "launch",
"name": "Launch Program",
"type": "pwa-node",
"program": "${workspaceFolder}/main.ts",
"cwd": "${workspaceFolder}",
"runtimeExecutable": "deno",
"runtimeArgs": [
"run",
"--unstable",
"--inspect",
"--allow-all"
],
"attachSimplePort": 9229
}
]
}
Example code
console.log("Hello, World!");
When I run this using by Run without Debugging
just shows like below image but expected to output Hello, World!.
and also seems debugging is not working.
Please help.

Debugging with --inspect does not work for relatively short programs, because it does not wait for the debugger to connect. So when running short programs the execution finishes before VS Code connects to the inspector. On larger programs this won't be an issue.
For debugging Deno programs that are only a couple of lines long, two options are given in this thread:
Use --inspect-brk instead of --inspect, this should allow enough time for the debugger to connect and hit breakpoints
Add some time delay to the code when debugging, for example:
const _sleep = async () => {
await new Promise(resolve => setTimeout(resolve, 2000));
}
await _sleep();
console.log("Hello World!"); <-- Here, you could add a breakpoint
To Run without Debugging, you can also either add --inspect-brk, but you will have to press F5 or click 'Continue' once the session has started. Or, you can use --inspect and add the sleep function

Related

Why does R Debugger fail to verify all breakpoints (Vscode)

I am using R Debugger in Vscode to develop an RShiny app while using SSH to connect to the remote.
My launch.json file looks like this:
{
"version": "0.2.0",
"configurations": [
{
"type": "R-Debugger",
"name": "Launch R-Workspace",
"request": "launch",
"debugMode": "workspace",
"workingDirectory": "", // If I put my actual path here, it changes nothing
"allowGlobalDebugging":true
}
]
}
For the purposes of this topic, I have these folders/files:
src/www/uis
src/server.R
I set breakpoints in files within src/www/uis as well as within src/server.R.
When I use Launch R-Workspace, the breakpoints at src/www/uis will trigger but within src/server.r they turn into "unverified breakpoints".
What I've tried:
Reading through similar questions and findings answers that did not seem relevant. Reading through the documentation where I did not see anything useful to me.
Any insight?
Thanks

How to Debug Amplify JavaScript functions in VS Code

How can I debug Amplify JavaScript functions on VS Code on Windows 10?
This issue came up on github under How to debug amplify function using visual studio code during invocation?, but it's closed and quite old. For example, amplify invoke function is deprecated in favor of amplify mock function.
I've tried this launch.config:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Create Reort",
"type": "node",
"request": "launch",
"program": "${env:APPDATA}/npm/node_modules/#aws-amplify/cli/bin/amplify",
"args": [
"mock",
"function",
"sayhello",
"--event",
"src/event.json",
"--timeout",
"0"
],
"console": "integratedTerminal"
}
]
}
Which will log the output, but doesn't hit any breakpoints inside the function being executed:
Setup steps:
Install amplify cli
npm install -g #aws-amplify/cli
Initialize amplify. Choose JavaScript with any framework.
amplify init
# Choose your default editor: Visual Studio Code
# Choose the type of app that you're building: javascript
# What javascript framework are you using: none
Add function
amplify add function SayHello
# Choose the runtime that you want to use: NodeJS
# Choose the function template that you want to use: Hello World
Here's a kinda hacky workaround.
As far as I can tell there isn't that much magic to lambdas for a single execution (The special sauce in the runtime environment, event handling, and auto scalability). The Amplify CLI passes in the event object from event.json and calls the function defined as the handler. You can do that in vanilla node js as well.
Create a file like debug.js - you can put it anywhere you want, but mine is in the .vscode directory
const { handler } = require("../amplify/backend/function/sayHello/src")
const event = require("../amplify/backend/function/sayHello/src/event.json")
(async function(){
// invoke
const response = await handler(event)
console.log(response)
})()
Then you can use a normal node js debug launch configuration like this:
{
"name": "Debug Function",
"program": "${workspaceFolder}/.vscode/debug.js",
"request": "launch",
"skipFiles": ["<node_internals>/**"],
"type": "pwa-node"
}
Something a little friendlier / out-of-the-box would be nice, but this at least allows step through debugging without too much extra work.
This used to work in an older version of VS Code. I opened https://github.com/aws-amplify/amplify-cli/issues/6894 to hopefully address the issue.
Meanwhile, here's another hacky workaround suggested here that uses Node's injector. Add this code to the top of your handler method (making sure you remove it before committing):
require('inspector').open(9229, '127.0.0.1', true);
debugger;
Be sure to set a long enough timeout in the amplify mock command in launch.json. To step through the code, you can use Chrome's Node debugger by navigating to about:inspect and clicking on "Open dedicated DevTools for Node".

VS Code debugger no longer accepting input

Strangely, VS Code stopped accepting input from integrated and external terminals. It was working with fish as the shell on Arch an hour ago. If I run the following Python code, for example:
print('Please enter a number: ', end='')
a = float(input())
print(f'Your number is: {a}')
and I type 1 and hit Enter, the cursor moves to the next line and all execution halts. The debugger is still running as if I didn't enter anything, but the terminal is displaying my input. When I hit stop, I see the error "timeout after 1000ms" as an alert in the lower right of VS Code.
I haven't made any changes to launch.json after generating from the Python: Current File option. For clarity's sake, that code is here:
{
// 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": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal"
}
]
}
I haven't found any resolution by reading the docs. Is this just a bug that will get fixed, or am I doing something wrong?
Edit
Executing the code from the shell normally runs as expected.
https://github.com/microsoft/vscode-python/issues/13449
check this out, try downgrade the extension back to another version.

Node debugging, make `${file}` dynamic?

With the right debug config file I can make VSCode run the currently focussed file through Mocha. However, I find it frustrating that if I am working on the actual code, rather than the spec file and I press F5, it tries to run the actual code as a spec file through Mocha.
So, my question is; given a file structure like this:
Folder
File.js
File.spec.js
And a debug config (.vscode/launch.json) like this:
{
// 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": "node",
"request": "launch",
"name": "Unit Tests: Current File",
"program": "${workspaceRoot}/node_modules/.bin/_mocha",
"cwd": "${workspaceRoot}",
"args": [
"-u", "tdd",
"--timeout=999999",
"--colors",
"--opts", "${workspaceRoot}/mocha.opts",
"${file}" // I want to make this dynamic
],
}
]
}
Is it possible to get VSCode to debug the spec file whether the spec file (File.spec.js) or it's subject (File.js) are selected?
You can introduce a new dynamic variable by writing a simple extension that just defines one command, e.g. a smartFile command.
Then you can refer to that command in your launch config as ${command:smartFile}.
For the implementation of the command you can use everything available in VS Code extension API. So you can not only calculate a path based on your folder structure, but you can even pop-up UI. E.g. you could use QuickPick to select a test case from the list of all tests.

Cannot debug in VS Code by attaching to Chrome

I have default config in launch.json. The site runs on port 8080.
{
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8080",
"webRoot": "${workspaceRoot}"
},
{
"type": "chrome",
"request": "attach",
"name": "Attach to Chrome",
"port": 9222,
"webRoot": "${workspaceRoot}"
}
]
}
However, when I click on the Debug button, I get this error:
Cannot connect to the target: connect ECONNREFUSED 127.0.0.1:9222
Question 1: Why does VS Code assign port 9222 when creating this json?
What is so special about this port that MS decided to put it in this launch.json?
Question 2: What do I need to change to make things work?
The Launch debug always launches a new window.
I am asking specifically about Attach debug option, so that it will open in a new tab instead.
When using the configuration url, vscode will search for a tab with the EXACT url and attach to it if found.
Use the configuration urlFilter, which can have wildcards like *, to attach the debugger to any sub route in your url.
e.g. "urlFilter": "http://localhost:4200/*"
The complete exacts steps to take:
configure your launch.json file to looks something like this:
{
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "attach",
"name": "Attach to Chrome",
"port": 9222,
"urlFilter": "http://localhost:4200/*",
"webRoot": "${workspaceFolder}"
}
]
}
Close all opened chrome instances (make sure that all of them are killed using task manager in windows).
Launch chrome with the following parameter: --remote-debugging-port=9222
Make sure that the port in this parameter is the same as the one configured in 'port' property of the attache to chrome configuration in the launch.json file (like the example above)
You can add this parameter in your chrome shortcut properties by:
Right click your shortcut file and select properties
Chain it to Target property, e.g.
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222
Navigate to your site. In this example, http://localhost:4200
Run 'Start debugging' in VS Code.
You need to install Debugger for Chrome extension for this to work. Open extensions in VS Code and search for Debugger for Chrome
You need to run a web server on the URL specified in the first configuration (default to http://localhost:8080). I use serve npm package that I installed globally. From my app folder I run serve -p 8080
Select Launch Chrome against localhost option. It will launch the browser and you can set breakpoints in your code and the debugging should work.
Regarding the second configuration (Attach to Chrome). There's nothing special about the port. In order to attach to Chrome you need to run Chrome with remote debugging enabled on port specified in the config. For example chrome.exe --remote-debugging-port=9222. I personally never use this options. Just follow the three steps above and you should be fine.
The Debugger for Chrome extension is deprecated. You do not need it anymore.
I came across this question when looking for help using the "Attach to Chrome" configuration in VSCode. While the accepted answer did give me a few hints, I did have to do some more digging. Here are the steps that worked for me in case anyone else finds them useful:
Install the Debugger for Chrome extension in VSCode Skip this, it's not needed anymore
Serve your files with a web server of your choice
Launch Chrome with remote debugging enabled
In this new Chrome window navigate to the url that your web server is hosting (http://localhost:8080 for example).
In VSCode, add a configuration to your launch.json file that looks like this:
"configurations": [
{
"type": "chrome",
"request": "attach",
"port": 9222,
"name": "Attach Chrome",
"url": "http://localhost:8080/",
"webRoot": "${workspaceFolder}"
}
]
Press the play button in VSCode with the 'Attach to Chrome' option selected from the drop down.
The key thing needed in the configuration file is the url field. This needs to be the URL where your files are being hosted and this URL needs to be currently open in the Chrome window that you just launched with remote debugging enabled. If you enter everything else right except this field, VSCode will give you an error message that says which urls are available. Something like Cannot connect to runtime process, timeout after 10000 ms - (reason: Can't find a valid target that matches: localhost:8080/. Available pages: ["http://localhost:8080",...
For the sake of completeness, here's how you launch Chrome with remote debugging enabled (from the Debugger for Chrome README):
Windows:
Right click the Chrome shortcut, and select properties
In the "target" field, append --remote-debugging-port=9222
Or in a command prompt, execute <path to chrome>/chrome.exe --remote-debugging-port=9222
MacOS:
In a terminal, execute /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
Linux:
In a terminal, launch google-chrome --remote-debugging-port=9222
A 2020 complement answer...
VS Code has a new debug that is not stable yet but works as default on Insiders version at the moment.
It opens automatically a new Chrome instance with debugging for attached with these settings:
{
"name": "Attach to Chrome",
"port": 9222,
"request": "attach",
"type": "pwa-chrome",
"webRoot": "${workspaceFolder}/src"
}
Like any attached, you can run the debug any time at this new window opened by VS Code.
Or you can run the Chrome as debug mode previously to avoid the VS Code to open a new debug window just like #quicklikerabbit answer https://stackoverflow.com/a/51392142/7050878 but this time without the need of the URL parameter.
The following procedure is for React applications created by create-react-app:
Click the Extensions button in the Activity Bar and install the Debugger for Chrome extension if it's not already installed.
Open a new Terminal window. cd to the client folder if necessary and install chrome-launcher:
npm install chrome-launcher
Switch to the Debugger panel in the Side Bar.
Click the Configuration drop-down at the top of the Side Bar and choose "Add Configuration..." Alternatively, press the little gear icon at the top of the Side Bar to open launch.json and then press the big blue button labeled "Add Configuration..."
From the list of configuration templates, choose Chrome: Attach. The following configuration should be added to launch.json:
{
"name": "Attach to Chrome",
"port": 9222,
"request": "attach",
"type": "pwa-chrome",
"webRoot": "${workspaceFolder}"
},
There's no need to change anything in this configuration.
Add a new file named .env with the following content to the root folder of your project (or to the root of the client folder if it's a full-stack application):
BROWSER=launchChrome.js
Add a new file named launchChrome.js to the same folder, with the following content:
const chromeLauncher = require('chrome-launcher');
chromeLauncher.launch({
startingUrl: process.argv[2],
port: 9222,
}).then(function (chrome) {
console.info('Chrome remote debugging port:', chrome.port);
});
Launch your React app from the Terminal window:
npm start
After a few seconds, you should see the following text:
Starting the development server...
Chrome remote debugging port: 9222
At the top of the Side Panel, choose the configuration Attach to Chrome and press the green triangle.
You can now place breakpoints in your React code and the debugger will break when it hits them. You can even debug your server and your client simultaneously by adding a Node.js: Launch Program configuration to launch.json.
I will put my measly two cents in :) unfortunately or fortunately I had a similar problem and the above post pointed me in the right direction and I learned a little something along the way. Please see my notes below:
1) If you are on Linux, after starting vsCode run the following Linux command:
sudo lsof -i -P -n | grep LISTEN
this will allow you to see what ports are being used, in my case you can see code on 5500.
2) Assuming you have some test html/js code and vsCode has a server and debugger installed then the following files need to be configured as such:
code-workspace file:
/*
Workspace settings override user settings.
https://code.visualstudio.com/docs/getstarted/settings
Check to see if needed ports are listening: sudo lsof -i -P -n | grep LISTEN
*/
{
"folders": [
{
"path": "."
}
],
"settings": {
"liveServer.settings.AdvanceCustomBrowserCmdLine": "google-chrome-stable --remote-debugging-port=9222",
}
}
launch.json:
{
/*
Workspace settings override user settings.
https://code.visualstudio.com/docs/getstarted/settings
Check to see if needed ports are listening: sudo lsof -i -P -n | grep LISTEN
*/
"version": "0.2.0",
"configurations": [
{
"name": "Launch 127.0.0.1:5500",
"type": "chrome",
"request": "launch",
"url": "http://127.0.0.1:5500/${relativeFileDirname}/${fileBasename}",
"webRoot": "${workspaceFolder}/${relativeFileDirname}"
},
{
"name": "Attach 127.0.0.1:5500",
"type": "chrome",
"request": "attach",
"port": 9222,
"url": "http://127.0.0.1:5500/${relativeFileDirname}/${fileBasename}",
"webRoot": "${workspaceFolder}/${relativeFileDirname}/"
},
]
}
setting.json:
/*
Workspace settings override user settings.
https://code.visualstudio.com/docs/getstarted/settings
Check to see if needed ports are listening: sudo lsof -i -P -n | grep LISTEN
*/
{
"cSpell.language": "en",
"git.enableSmartCommit": true,
"git.autofetch": true,
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"liveServer.settings.donotShowInfoMsg": true,
"cSpell.userWords": [
"lsof",
"readonly"
],
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"cSpell.enabledLanguageIds": [
"asciidoc",
"c",
"cpp",
"csharp",
"css",
"git-commit",
"go",
"handlebars",
"haskell",
"html",
"jade",
"java",
"javascript",
"javascriptreact",
"json",
"jsonc",
"latex",
"less",
"markdown",
"php",
"plaintext",
"pug",
"python",
"restructuredtext",
"rust",
"scala",
"scss",
"text",
"typescript",
"typescriptreact",
"yaml",
"yml"
],
}
3) NOTE make sure all browsers are closed before starting up the 'Live Server'. Spin-up your server 'Live Server'to open the file you would like to debug as per the configuration for the chrome browser stipulated in the vsCode File>Preferences>Settings, NOTE use 127.0.0.1 I had no luck with localhost, also the default port is 5500. The browser is now launched as per the vsCode-workspace file setting "liveServer.settings.AdvanceCustomBrowserCmdLine": "google-chrome-stable --remote-debugging-port=9222", this is where the debug magic takes place. NOTE make sure all browsers are closed before starting up the 'Live Server'.
Especially check to make sure there are no chrome extension like Hangouts running, this will also prevent Chrome from opening port 9222, I had to click the Exit option on the task to kill all Chrome extension in my example:
4) Now if you run sudo lsof -i -P -n | grep LISTEN you will see vsCode 'Live Server' serving on port 127.0.0.1:5500 and the debugger doing its thing on port 127.0.0.1:9222; If you do not see both ports opened then something is not correct and you will need to confirm STEP 3) listed above.
5) You can check the web interface for the debugger by entering http://127.0.0.1:9222/ in a empty browser tab, this url will display links to every tab and extensions open and allow you to poke around with the debugger, click on the link to the file you want to debug, in my case 127.0.0.1:5500/Leason_66/index.html, this is the port and link vsCode will communicate with and re-render in the IDE Debugger.
6) Note: Make sure you are on the file you want to debug. We are almost there, now just click on the Debug Icon then go to the GREEN Play Button and select the attach option from the drop down, please note the information configured in the launch.js file is what will appear in the drop down.
7) Time for some action! Now all you have to do is click on the GREEN Play Button and the Debugger will now attach to tab you have open at 127.0.0.1:5500/<path you your file> and do its debug on port 127.0.0.1:9222
8) Happy Engineering :)
Try this:
"type": "edge",
"request": "launch",
"name": "Launch Edge",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}"
"file": "${workspaceFolder}/index.html"
Peek into Task Manager. You may have Chrome instances hanging there. Only after killing them will you be able to run the remote and successfully start the debugger.
Run Chrome on macOS without command lines.
We'll create a shortcut of Chrome that will run --remote-debugging-port=9222 for us.
Steps
Open the native application called Automator.
It opens a selector. Our goal is to create an application, hence we choose Application.
Look for shell.
Add the next script /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222
Then save it with your desire. Our application shortcut is done.
Run the Spotlight with CMD + Space and type your app name, mine starts with Chrome Debug. Open it and voilĂ 
Add the launch.json this configuration (you can edit the localhost's port):
{
"name": "Chrome lh:4200",
"type": "chrome",
"request": "attach",
"urlFilter": "http://localhost:4200/*",
"port": 9222,
"webRoot": "${workspaceFolder}"
}
Run that debug configuration. VSCode is waiting. Open your localhost URL on the Chrome, VSCode debugger will show this state: