Jest-Runner is changing breakpoints after last vscode update (to 1.60.00)

[Lutier2017]

Hi, I have been using Jest-Runner in a JS project. I was using Jest-Runner version 4.34 Everything was working good. Just after last vscode update 1.60.00, breakpoints stopped to work properly. I moved to Jest-Runner version 4.44, BUT problem remains. NOTE: I reviewed all previous issues in GITHUB, BUT none describes the problem I have found.

Short issue description is:

1) Before, I was able to set a breakpoint in a Jest Test File. When running debugger, executed stops in that breakpoint. This was OK.

2) After vscode update, when running debugger the breakpoint is moved to another New File. New File is a copy of the Jest Test File with injected code (maybe by babel, or Jest). New breakpoint location is not the same one as in Jest Test File.

I have followed all your indication in the web page: https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner BUT problem remains.

I appreciate your reply.

Please find at the end further descriptions about my installation, and problem.

NOTE: feel free to ask for any further information

VSCODE installation.

Windows 10 JS project.

Jest-Running BEFORE VSCODE update

1) "Run" and "Debug" were working find. 2) Both "Run" and "Debug" were running with Git-Bash. 3) Breakpoint did not move during degugging.

Jest-Running AFTER VSCODE update to 1.60.00

1) "Run" now is running with Powershell, instead of Git-Bash. 2) "Debug" remains running with Git-Bash, BUT, breakpoints are moving to a New File. 3) New File is a copy of the Jest Test File with injected code (maybe by babel, or Jest).

Example of test code in Jest Test File where breakpoint is located

describe("'lwpmRef' general class test", () => {

    test("Create a 'lwpmRef' object", () => {

        let attRef = new lwpmRef( "PV", lwCode.lwAttReal )

        expect( attRef.Value ).toBeUndefined()

Example of test code in New File where breakpoint is now moved NOTE: New File is a copy of the Jest Test File with injected code (maybe by babel, or Jest).

describe("'lwpmRef' general class test", function () {
  test("Create a 'lwpmRef' object", function () {
    var attRef = new _lwpmRef.lwpmRef("PV", _lwCode.lwCode.lwAttReal);
    expect(attRef.Value).toBeUndefined();

ANOTHER Example where breakpoint is located in a JS file

class lwpmRefAtt extends lwpmRef {

  constructor(nameRef, valLWcode, dvr = "") {
    // Create and verify "Name" property.
    super(nameRef, valLWcode, dvr);
}

ANOTHER Example where original breakpoint is moved to a new JS file

var lwpmRefAtt = /*#__PURE__*/function (_lwpmRef) {
  _inherits(lwpmRefAtt, _lwpmRef);

  var _super = _createSuper(lwpmRefAtt);

  function
  /* istanbul ignore next */
  lwpmRefAtt(nameRef, valLWcode) {
    /* istanbul ignore next */
    var _this;

    var dvr = arguments.length > 2 && arguments[2] !== undefined ? arguments[2] : (cov_2f9mg23sbr().b[0][0]++, "");

    /* istanbul ignore next */
    _classCallCheck(this, lwpmRefAtt);

    cov_2f9mg23sbr().f[0]++;
    cov_2f9mg23sbr().s[0]++;
    // Create and verify "Name" property.

    /* istanbul ignore next */
    _this = _super.call(this, nameRef, valLWcode, dvr);
  }

[Lutier2017]

Hi, I got some progress solving the problem.

In addition to your indications in: https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner

I attached babel configuration in "package.json", as follows:

  "babel": {
    "presets": [
      "@babel/preset-env"
    ],
    "sourceMap": "inline",
    "retainLines": true
  },

Now the New File (as described in my previous post), is a copy of Jest Test File, BUT without injected code. In this way is easier to do the test.

For me it is clear the problem IS NOT in "Jest-Runner", nevertheless I appreciate any help to get rip of New File, to continue testing as before (No New File).

[Lutier2017]

The problem was solved after downgrading VSCODE from version 1.60.0 to 1.59.1

[darioscattolini]

I had a similar issue, my debug attempts don't stop at breakpoints anymore. Spent hours trying to solve it through settings files until I found this thread. I downgraded VSCode to 1.59 and it works perfectly again.

@Lutier2017 Perhaps the issue should not be closed, there seems to be an incompatibility between the extension and the new version of VSCode that should be resolved.

[Lutier2017]

Hi @darioscattolini,

I agree with you that the issue should not be closed. I reopened it again. Hopefully, somebody could come with a solution for VSCODE version 1.60.0.

Regarding the extension, I have not enough information to believe that the problem is in the Jest-Runner extension. The extension only builds the command line to run Jest from Node. I did not identify any problem about the built command. May be @firsttris can confirm this observation.

In fact what I saw is: VSCODE 1.60.0 is not aware of the "Source Maps" to properly handle breakpoints. When I downgraded to VSCDE 1.59.1, the problem disappeared.

[PizzaPartyInc]

Hey!

I have a hunch that this issue is related to the fact that Jest Runner might be using a legacy node debugger, while VSCode 1.60 finally dropped the support for it. I think I briefly saw a VSCode notification in the past that an obsolete debugger was used when debugging tests, but it appeared only once and I never saw it again.

[christianarg]

I've observed similar behavior after updating to 1.6.0 in my case with typescript. Previously I could set the breakpoint and debug directly the ts / tsx file. Now when debugging vscode opens the generated file and I must debug now the generated JavaScript file. Also the breakpoints lines are not respected. The only way is to write a debugger statement

[firsttris]

hey @PizzaPartyInc

thx for clarifying.

is it possible to migrate the extension to the new debugger?

this is our current debug config: https://github.com/firsttris/vscode-jest-runner/blob/master/src/jestRunner.ts#L133

[PizzaPartyInc]

@firsttris I never worked with vscode extension code and/or debugger-related code, so it's hard to say. If I had to figure it out, I'd have to investigate how the current version of extension is working, try to find some updated documentation for debugging API, perhaps ask some questions in vscode-related github or search existing issues there. Unfortunately, I cannot imagine myself having free time to do so in the near future :/ But I would expect there to be a way to migrate, it would not make sense to just drop the old API and not introduce the new one.

[firsttris]

its pretty much the same as the launch.json configration only as object

    const config: vscode.DebugConfiguration = {
      console: 'integratedTerminal',
      internalConsoleOptions: 'neverOpen',
      name: 'Debug Jest Tests',
      program: this.config.jestBinPath,
      request: 'launch',
      type: 'node',
      cwd: this.config.cwd,
      ...this.config.debugOptions,
    };

my understandig is we need to debug configuration for the new debugger?

[arcollector]

i'm encountered this same problem with the latest vscode (1.60)

[BrutalSimplicity]

For those that have run into this issue, I've found that just running the test (as opposed to debugging) with jest-runner and then using the auto-attach feature in VSCode (https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_auto-attach) seems to produce the correct behavior for breakpoints.

[firsttris]

does this mean we can remove the debug feature and use the auto attach feature instead ?

maybe its possible to trigger the auto attach from api as well....

[sim099]

does this mean we can remove the debug feature and use the auto attach feature instead ?

maybe its possible to trigger the auto attach from api as well....

There were two reasons that I started using this particular plugin. One was because it worked for me, where others didn't seem to do so and the other is because of the ability to run or debug individual tests/describe blocks/test files by simply selecting which of the "floating links" (not sure if there's an official term or not) that appear in the test files.

Simply removing the Debug "links" and requiring the user to enable auto-attach would remove a lot of the convenience that I like and have gotten used to. It would also result in all code executed via VSCode running in debug mode unless the user changes the IDE configuration inbetween executions.

If it's decided that using auto-attach is the way to go then would it be possible to keep the Debug "links" and have then pass the --inspect flag? That way, I think we should be able to keep auto-attach confiured to "Only With Flag" and not have to change it again inbetween debugging and running tests.

[firsttris]

@sim099 thx for your feedback, that seems like the best option

[sim099]

Do the workarounds still work for anyone?

I was still using VSCode 1.59.1 and Jest Runner 0.4.43 earlier this morning, but breakpoints within tests were moving any time I debugged a test... including via auto-attach.

I thought I'd just move on to using the work around, so upgraded both VSCode to 1.62.2 and Jest Runner to 0.4.47 (along with other pending add-on updates, but I doubt that's relevant) but the breakpoints are still moving whether I use the Run or Debug link.

Also, using the "Run and Debug" button in VSCode seems to attempt to run something (and briefly shows the debug toolbar) but then exits and doesn't even show a console window. Creating a launch.json file using the default Node.js configuration hasn't helped. I only started using VSCode recently and started using Jest Runner immediately after, so haven't got much experience in this area of the IDE and am a little lost...

I realise that I may need to research running/debugging within VSCode independently of this thread, but wanted to post here because I know there's at least a few people with a similar experience and solutions or workarounds may already have been found.

Anyone have any advice?

Thanks!

[blaisn]

With VSCode 1.62.2 and Jest Runner v0.4.47, I can reproduce the problem:

describe(`test bug "describe"`, () => {
    const foo = 1;
    it(`Success "1"`, async () => {
        expect(foo).toBe(1);
    });
});

1. Put a breakpoint at the "expect" line
2. Hit "debug" code lens (either describe or it level)
3. The breakpint is never reached
4. The test is completly skip
5. The "Run" code lens gives expected result: the test is not skip.

Debug problem solved when we remove double quotes in the describe and it:

describe(`test bug describe`, () => {
    const foo = 1;
    it(`Success 1`, async () => {
        expect(foo).toBe(1);
    });
});

I suppose that those double quotes could interfere in the regex used to match the test we point out within the file.

[firsttris]

is this issue fixed with 0.4.48?

[Lutier2017]

Hi,

For the last 3 months, I have been using:

• VSCODE 1.63.2
• Jest Runner v0.4.47
• vscode-Jest v0.4.2.1
• Jest 27.1.0

It is comfortable to work. No severe problems.

The only issue I have seen is that the checked breakpoints sometimes are moved when I run the debugger. BUT If:

• I leave checked only the first checkpoint I want, and
• I uncheck all the other checkpoints, Then, the other checkpoints do not move.

After the debuggers stops in the first checkpoint, I can check the others and debugger runs properly.

[blaisn]

The test case I have presented on 2021-11-16 is still showing the exact same easy to reproduce bug using: VSCdoe 1.67.1 Jest-Runner: 0.4.48 Jest 27.5.1 Is it possible to reopen the issue?