vscode debug + typescript recipes are incompatible as authored

cdaringe commented 3 years ago

Please provide details about:

What you're trying to do

debug tests, in typescript, ts-node only

What happened

Test executed successfully, but both breakpoints & debugger statements ignored

ava_no_break mov

What you expected to happen

debugger statements to halt execution

per using-ts-node, some TS configuration is needed in package.json. i've added:

  "ava": {
    "extensions": [
      "ts"
    ],
    "require": [
      "ts-node/register/transpile-only"
    ],
    "files": [
      "test/**/*.test.ts"
    ]
  }

per creating-a-launch-configuration, various launch configuration is required:

    {
      "type": "node",
      "request": "launch",
      "name": "Debug AVA test file",
      "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/ava",
      "runtimeArgs": ["${file}"],
      "outputCapture": "std"
      // "skipFiles": ["<node_internals>/**/*.js"] // i've disabled simply to remove more variables
    }

Interestingly, I can get into a breakpoint if I execute a alternate debugging workflow:

npx ava debug test/class.test.ts
Attach a debugger

Works fine :)

Previously, ava entered a debug session via more idiomatic node debug conventions--node --inspect <path/to/ava/profile.js> <test name>. It seems like now ava is doing some fancy footwork, where it wants to start the node debugger, where VSCode also wants to start the debugger, and consequently these two things may be trampling each other a bit.

I don't have a minimal repro, but it's a pretty straightforward repro:

git clone https://github.com/cdaringe/factorio-ts
git checkout 7cbc8e9
yarn
execute the VSCode launch as recorded above
observe.

We'll also need your AVA configuration (in package.json or ava.config.* configuration files) and how you're invoking AVA. Share the installed AVA version (get it by running npx ava --version).

Shared above, but here's also envinfo output:

  System:
    OS: macOS 11.1
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Memory: 637.21 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 15.0.1 - ~/.fnm/current/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.0.3 - ~/.fnm/current/bin/npm
  Managers:
    Cargo: 1.42.0 - ~/.cargo/bin/cargo
    Homebrew: 2.6.2 - /usr/local/bin/brew
    pip2: 19.3.1 - /usr/local/bin/pip2
    pip3: 20.3.1 - /usr/local/bin/pip3
    RubyGems: 3.0.3 - /usr/bin/gem
  Utilities:
    CMake: 3.13.0 - /usr/local/bin/cmake
    Make: 3.81 - /usr/bin/make
    GCC: 4.2.1 - /usr/bin/gcc
    Git: 2.19.0 - /usr/local/bin/git
    Clang: 1103.0.32.62 - /usr/bin/clang
    FFmpeg: 4.0.2 - /usr/local/bin/ffmpeg
  Servers:
    Apache: 2.4.46 - /usr/sbin/apachectl
  Virtualization:
    Docker: 20.10.2 - /usr/local/bin/docker
  SDKs:
    iOS SDK:
      Platforms: DriverKit 19.0, macOS 10.15
  IDEs:
    Nano: 2.0.6 - /usr/bin/nano
    VSCode: 1.52.1 - /usr/local/bin/code
    Vim: 8.2 - /usr/bin/vim
    Xcode: 11.7/11E801a - /usr/bin/xcodebuild
  Languages:
    Bash: 5.0.11 - /usr/local/bin/bash
    Go: 1.11.1 - /usr/local/bin/go
    Elixir: 1.9.1 - /usr/local/bin/elixir
    Erlang: 22.0.7 - /usr/local/bin/erl
    Java: javac 11 - /usr/bin/javac
    Perl: 5.28.2 - /usr/bin/perl
    PHP: 7.3.24 - /usr/bin/php
    Python: 2.7.17 - /usr/local/bin/python
    Python3: 3.9.1 - /usr/local/bin/python3
    Ruby: 2.6.3 - /usr/bin/ruby
    Rust: 1.42.0 - /Users/cdaringe/.cargo/bin/rustc
  Databases:
    SQLite: 3.32.3 - /usr/bin/sqlite3
  Browsers:
    Chrome: 87.0.4280.88
    Firefox: 84.0.1
    Safari: 14.0.2

novemberborn commented 3 years ago

Do you need to create the launch configuration? The built-in debug terminal works pretty well for me, and so I haven't used launch configurations in a while…

I wonder if the debug command is missing from runtimeArgs. It was removed in https://github.com/avajs/ava/pull/2547. Could you try putting it back in?

rgomezp commented 3 years ago

Howdy! Same issue.

I have to use launch configuration because I'm using TS so the code has to be first transpiled and then run via the preLaunchTask param. I have two configurations: 1) "Transpile & Run" and 2) "Run"

{
    "version": "0.3.0",
    "configurations": [
        {
            "name": "Transpile & Run",
            "preLaunchTask": "transpile",
            "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/ava",
            "runtimeArgs": [
                "debug",
                "--break",
                "--verbose",
                "--color",
                "--serial",
                "--watch=false",
                "build/ts-to-es6/test/**/${fileBasenameNoExtension}.js",
            ],
            "request": "launch",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "node",
            "outputCapture": "std",
            "port": 9229,
            "sourceMaps": true,
            "trace": true,
            "protocol": "auto",
            "console": "integratedTerminal"
        },
        {
            "name": "Run",
            "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/ava",
            "runtimeArgs": [
                "debug",
                "--break",
                "--verbose",
                "--color",
                "--watch=false",
                "--fail-fast=false",
                "build/ts-to-es6/test/**/${fileBasenameNoExtension}.js",
            ],
            "request": "launch",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "node",
            "outputCapture": "std",
            "port": 9229,
            "sourceMaps": true,
            "trace": true,
            "protocol": "auto",
            "console": "integratedTerminal"
        },
    ]
}

For me, everything was working up to VSCode version 1.46.1 and then there was some regression on higher versions. Then I updated my project's Typescript version and it seems that there is a different regression because the VSCode version stayed the same. This issue is related to the latter.

You can reproduce this in the OneSignal WebSDK

Debug breakpoints completely ignored

rgomezp commented 3 years ago

Update: I tried putting a debugger; statement to halt execution. This works but opens the transpiled version (JS). Then, if I add breakpoints they work but I have to add them in the transpiled version of the file

novemberborn commented 3 years ago

@rgomezp have you tried the built-in debug terminal? I run a TypeScript compiler in a separate process, but for be this works great for debugging tests.

rgomezp commented 3 years ago

@novemberborn , Hi Mark. I'm sorry but I'm not sure what you mean exactly. I have "console": "integratedTerminal" set in my launch config. Perhaps a gif or video could help clarify?

novemberborn commented 3 years ago

As in here: https://github.com/avajs/ava/blob/master/docs/recipes/debugging-with-vscode.md#debugging-with-the-debug-terminal

From the Command Palette (F1 or command + shift + p / control + shift + p), run Debug: Create JavaScript Debug Terminal

rgomezp commented 3 years ago

@novemberborn , I tried it. Unfortunately not, I see this:

➜  OneSignal-Website-SDK git:(master) npx ava                                       
Debugger listening on ws://127.0.0.1:55969/c73ff059-1228-4a02-89ea-3fc705bf07ce
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.

⠙ Debugger listening on ws://127.0.0.1:55983/68406bfa-8140-4449-89e2-0672b8684c1d
For help, see: https://nodejs.org/en/docs/inspector
⠸ Debugger attached.
⠹ Waiting for the debugger to disconnect...
⠴ Debugger listening on ws://127.0.0.1:55991/73b07842-0231-4620-a5b3-1aecb57c7229
⠦ For help, see: https://nodejs.org/en/docs/inspector
⠇ Debugger attached.
⠇ Waiting for the debugger to disconnect...
⠋ Debugger listening on ws://127.0.0.1:55995/05bb11c6-1ef1-4fd0-aab1-e42b22c2a32f
For help, see: https://nodejs.org/en/docs/inspector
⠸ Debugger attached.
⠹ Waiting for the debugger to disconnect...
⠼ Debugger listening on ws://127.0.0.1:55995/05bb11c6-1ef1-4fd0-aab1-e42b22c2a32f
For help, see: https://nodejs.org/en/docs/inspector
⠦ Debugger listening on ws://127.0.0.1:56003/7fb34994-2435-4cb6-8be9-6bac966066b8
For help, see: https://nodejs.org/en/docs/inspector
⠇ Debugger attached.
⠋ Waiting for the debugger to disconnect...
⠹ Debugger listening on ws://127.0.0.1:56011/850140cb-ffee-44ef-90dc-441765b78125
For help, see: https://nodejs.org/en/docs/inspector
⠼ Debugger attached.
  ✖ No tests found in build/ts-to-es6/test/unit/helpers/ConfigHelper.js
  ✖ No tests found in build/ts-to-es6/test/unit/helpers/InitHelper.js
  ✖ No tests found in build/ts-to-es6/test/unit/helpers/MainHelper.js
  ✖ No tests found in build/ts-to-es6/test/unit/helpers/ServiceWorkerHelper.js

novemberborn commented 3 years ago

I think that may have more to do with your project setup.

I did clone your project, ran npx tsc --project build/config/tsconfig.tests.json and then from VSCode ran npx ava and that ran the tests fine.

There's a lot of moving pieces in your project and I reckon that's where the trouble lies.

Not to say the recipe is perfect, of course, I suspect the debug command is still missing? https://github.com/avajs/ava/issues/2640#issuecomment-758532588

rgomezp commented 3 years ago

@novemberborn thanks for your response.

You can see the debug command in my configuration in this comment.

So I am using that.

I ran the npx tsc --project build/config/tsconfig.tests.json && npx ava command and it ran the tests fine.

That's not the original issue however. The problem is the breakpoints aren't triggered.

novemberborn commented 3 years ago

The recipe works as-is with a plain JavaScript project.

Adding TypeScript, and build steps, makes everything more complicated. I don't know if that's solvable within our recipes.

FWIW I use the debug terminal along with @ava/typescript (which requires you to pre-compile the code). This works great. I'd love for you to try this so we can make more explicit that this works.

cdaringe commented 3 years ago

greetings all :) the recipe as written actually doesn't work with plain javascript.

to prove it, i've done the following:

created a new project
added test.js file
created a launch config, as recorded here
ran

reference to repro repository. Observe it all in this nice GIF! I debugged on the incorrect file at first--ignore that part 😉 !

plain_old_javascript mov

As you can see, the debugger statement is not hit, using plain javascript, using the official recipe. I also decided to edit the Ava source code that launches the subprocess to debug the matter further. You can see the above output that the worker is launched with "execArgv": []. Because of this, I don't expect the worker to be in debug mode (unless the subprocess kicks itself into debug mode dynamically, which is certainly possible via SIGUSR1).

FWIW, using the debug terminal works fine, as recommended here. ts-node is certainly compatible with all of this, as suggested in the typescript docs section. Precompiled assets also are not required using the debug terminal.

It's unclear to me what the design intent is supposed to be for the launch-configuration experience (which is my preferred experience). As shown above, the recipe does not kick the worker process into debug mode. Even if it did kick the child into debug mode, it's also unclear to me how one would get VSCode to listen to that child. In the prior state of ava, there was only one PID to hook into. Perhaps something like runInBand is in order to return the easy debug flow to the prior state?

novemberborn commented 3 years ago

@cdaringe could you confirm your AVA, Node and VS Code versions? I wrote the exact same fixture file yesterday which worked.

cdaringe commented 3 years ago

Certainly! Node 15.0.1, VSCode: 1.52.1, ava@3.15.0

envinfo posted below

System: OS: macOS 11.2 CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz Memory: 522.02 MB / 8.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 15.0.1 - ~/.fnm/current/bin/node Yarn: 1.22.10 - /usr/local/bin/yarn npm: 7.0.3 - ~/.fnm/current/bin/npm Utilities: CMake: 3.13.0 - /usr/local/bin/cmake Make: 3.81 - /usr/bin/make GCC: 16.088 - /usr/bin/gcc Git: 2.19.0 - /usr/local/bin/git Clang: 1200.0.32.29 - /usr/bin/clang Virtualization: Docker: 20.10.2 - /usr/local/bin/docker IDEs: VSCode: 1.52.1 - /usr/local/bin/code Xcode: 12.4/12D4e - /usr/bin/xcodebuild Languages: Bash: 5.0.11 - /usr/local/bin/bash Go: 1.11.1 - /usr/local/bin/go Elixir: 1.9.1 - /usr/local/bin/elixir Erlang: 22.0.7 - /usr/local/bin/erl Java: javac 11 - /usr/bin/javac Perl: 5.28.2 - /usr/bin/perl PHP: 7.3.24 - /usr/bin/php Python: 2.7.17 - /usr/local/bin/python Python3: 3.9.1 - /Library/Frameworks/Python.framework/Versions/3.9/bin/python3 Ruby: 2.6.3 - /usr/bin/ruby Rust: 1.42.0 - /Users/cdaringe/.cargo/bin/rustc Databases: SQLite: 3.32.3 - /usr/bin/sqlite3 Browsers: Chrome: 88.0.4324.96 Firefox: 84.0.1 Safari: 14.0.3

novemberborn commented 3 years ago

I didn't notice this before, but you run the debug command from the launch.json file. What the launch configuration does however is pass the currently active file to AVA, which, if it's a matching test file, will run it.

All this works for me, Node.js 15.8, VSCode 1.53, no AVA configuration.

I'm going to close this, since I don't think there's actually an issue here. Of course if the recipe needs updating I'll happily take a PR. It all works as advertised though… but that could just be my machine 😉

cdaringe commented 3 years ago

Bummer.

I've provided two demonstrations, code and visual
I found in the source code where the child test process is launched, and shared insight on how it is launched without debug flags when using the recipes as authored

I appreciate your effort and willingness, but I don't see compelling rationale for closure. "Works on my machine (with different config)" I feel is not giving the detailed reports justice. I'm not begging for an immediate solution, but I do kindly think the issue should be closed when it's certainly done-done.

Let me know your thoughts.

novemberborn commented 3 years ago

As far as I can tell, the configuration, as documented, works. VS Code injects code to enable debugging, so the previous approach is no longer required.

Any combination with ts-node introduces too many variables. I'd take a PR that documents how to make it work but I highly doubt leaving the issue open for that is going to result in one.

cdaringe commented 3 years ago

As you can see, the debugger statement is not hit, using plain javascript, using the official recipe.

I don't think my system is uncommon, as shown my envinfo. I even uploaded a reproduction repository for plainjs (ignore -ts in the repro repo url). I admit, I could be missing something. But, as mentioned above, I don't see ts-node as the issue.

Viscose injects

Are you assuming users are using autoattach? Otherwise I don't expect vs code to do this. I only expect it to add args to the root launch cli args to node

novemberborn commented 3 years ago

I even uploaded a reproduction repository for plainjs

git clone https://github.com/cdaringe/ava-ts-patcherooni
cd ava-ts-patcherooni
npm i
code .

Open test.js. Run Debug AVA test file.

This was Node.js 14.15.4 and VS Code 1.53.0.

I don't know why it's not working for you. I'm sorry I can't help further.

cdaringe commented 3 years ago

I tried on linux today (as opposed to my day-to-day macos laptop), and used the same node & vscode version as above. still doesn't take. ~however, despite that it works for you, i do not expect it to work for you. i'm not sure what about your system makes this work--perhaps an env config, perhaps a vscode extension, ...im not sure.~

~ava runs the test in a child process. nothing is kicking that child process into debug mode. i don't expect a debugger to hit, because the test runner isn't flipping on the node debugger in the child worker.~

~in your screen shot, you can see the parent/child relationship, and that you have broken in the child.~

...

annnnnnd a few interesting tid bits of research have shown up:

i can get the launch to break if I add "autoAttachChildProcesses": true. this gets the desired workflow to take, even if not included in the recipe (perhaps because it shouldn't be?)
built in debugger does claim to break on children/workers automatically, but there seems to be some conditionality to it

i need to learn more about what conditions would lead to requiring autoAttachChildProcesses or what conditions would cause VSCode js-debug to not issue its default behavior from the docs

cdaringe commented 3 years ago

By using "type": "pwa-node" and dropping autoAttachChildProcesses, it also works. Do you have "debug.javascript.usePreview": true set by chance?

novemberborn commented 3 years ago

Do you have "debug.javascript.usePreview": true set by chance?

I do! Not that I recall setting it.

Auto attaching to child processes sounds like it would be necessary. Would be good to know what is stock VS Code and what settings may be inherited from older installations. Or we can just say "use pwa-node", whatever that is.

rgomezp commented 3 years ago

Howdy, I'm in the same boat. Can you please reopen the issue?

novemberborn commented 3 years ago

If we can get to the bottom of it. Does changing the type help?

stevenpollack commented 2 years ago

I'm having the same issue wherein the stock recipe just seems to ignore vscode breakpoints. I'm using AVA v3.15 and vscode 1.65.2... Seems to only happen with WSL2, though. I can confirm the recipe is fine on Windows 11, and MacOS.

stevenpollack commented 2 years ago

Howdy, I'm in the same boat. Can you please reopen the issue?

I think I've figured out the issue. The source map resolution isn't working because VSCode doesn't know what the actual program name is. Try using the following configuration:

{
            "name": "Debug AVA",
            "type": "node",
            "request": "launch",
            "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/ava",
            "program": "${file}",
            "outputCapture": "std"
 }

the big issue was that we were passing ${file} to ava via runtimeArgs and not through program...

avajs / ava

vscode debug + typescript recipes are incompatible as authored #2640