VSCode doesn't hit breakpoint (running via node tsdx/dist/index.js test)

[orbachar]

Hi, I need a little help here, I am trying to debug jest tests using VScode debugger.
when running the debug mode, the application runs smoothly without hitting and stoping on breakoints.

this is my launch.json

    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Jest Test",
            "program": "${workspaceFolder}/node_modules/tsdx/dist/index.js",
            "args": [
                "test"
            ],
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "outFiles": ["${workspaceFolder}/dist"],
            "protocol": "inspector",

        }
    ]

Am I missing somehting?

[agilgur5]

Might be a duplicate of #439 but not sure, your configurations are different and you didn't say you got the same error EDIT: Nope, they're fairly different, notably that one didn't use tsdx/dist/index.js and this one doesn't use vscode-jest

I haven't tried using the debugger myself, so this still needs more investigation. The error in that issue led me down a rabbit-hole as it appears to be quite common for lots of different use-cases

[agilgur5]

Ok tried this out myself on one of my libraries and got it to work without much fuss. My launch.json has some differences:

        "version": "0.2.0",
        "configurations": [{
            "name": "Node.js: Debug TSDX Jest Tests",
            "type": "node",
            "request": "launch",
            "runtimeArgs": [
                "--inspect-brk",
                "${workspaceRoot}/node_modules/tsdx/dist/index.js",
                "test",
                "--runInBand"
            ],
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "port": 9229
        }]

Notably, --inspect-brk and that I didn't change the default program (from node) and instead added ${workspaceRoot}/node_modules/tsdx/dist/index.js to the args after --inspect-brk

Idk if this follows best practices but it does work

[or2008]

yes! works perfectly. thank you

[chmac]

Any chance to get this vscode launch script added to readme? I'd be happy to submit a PR if there's support to merge it. Was a life saver when I eventually found it! ❤️

[agilgur5]

@chmac I think this is more a workaround for a specific use-case; long-term I am aiming to make TSDX more compatible with various existing tools, like with #270, #354, and even #634 , as the incompatibilities certainly cause a bit of confusion

[chmac]

@agilgur5 In my case, I was trying to investigate why a test was failing, so I wanted to run it with breakpoints. I tried the default launch.json config from jest, but that didn't work, it was running the typescript files as javascript I think. Then I went down the rabbit hole of trying to figure out how to "eject" the jest config, etc, etc. When I eventually found the config you posted, it worked like a charm. I'd assume that's useful for some folks, but maybe a link to this issue would be enough in the readme?

[agilgur5]

@chmac well the root cause issue is really the first one you hit, the missing jest.config.js. I'm quite wary of adding workarounds to docs because they're generally brittle by nature and it makes it harder for the patch to then be adopted as the workaround has been adopted instead. It also de-prioritizes time/resources that contributors could use toward a root cause fix.

[chmac]

@agilgur5 Thanks for bearing with me with all my questions, I realise you're likely working on this in your spare time, etc, etc.

Maybe I'm missing something. I tried reading through #270 to see how testing would work. As I understand that issue, the conclusion (which I support) is to keep jest through tsdx test and via a jest preset, rather than a custom config. In the case where I'm running the mainline jest config, and don't want to make my own changes, and I want run a debugger on my jest tests, how would I do that without the launch.json here in this issue?

As far as I understand what's going on, adding the --inspect-brk before the call to tsdx test is going to be necessary. Unless tsdx test adds a flag or something, like tsdx test --node-debugger, which does this for us.

Again, maybe I'm missing something here. I do see your point that making workarounds more obvious is not a good idea. I understood that this approach was not really a workaround, but more of a "this is the best option unless we add an extra feature".

As an alternative, what about adding a "current workarounds" or similar label, then tagging some issues with it, and linking to that somewhere in the readme? I guess my sense is that if you land on this package today, and want to debug your jest tests, the launch.json in this repo is super useful. But I also see that encouraging people to hack stuff will make life harder later...

[agilgur5]

As I understand that issue, the conclusion (which I support) is to keep jest through tsdx test and via a jest preset, rather than a custom config.

With that and #634 , the intent is that you don't necessarily need tsdx test (or lint). It would basically exist to proxy dependencies and provide a default for when a user has no config (which will probably become a legacy state). That means you can use vscode-jest or whatever and a launch config is probably out-of-scope then if not unnecessary.

As an alternative, what about adding a "current workarounds" or similar label, then tagging some issues with it

This already exists in the pinned HOWTOs issue: #379.

[chmac]

@agilgur5 Got it, thanks for taking the time to explain it in detail to me, I really appreciate it.

The HOWTO pin makes total sense, I missed that one.

[vvo]

If you're looking at how to get vscode-jest support in your tsdx project, create a file named .vscode/settings.json and add this line:

{
  "jest.jestCommandLine": "npm test --"
}

I think the jest vscode extension is not working initially because it doesn't detect jest as a direct dependency.

I still think the implementation is not perfect because it seems to be slower than a regular setup but it works well.