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

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).

<u>Example of test code in Jest Test File where breakpoint is located</u>

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

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

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

        expect( attRef.Value ).toBeUndefined()

<u>Example of test code in New File where breakpoint is now moved</u> 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();

<u>ANOTHER Example where breakpoint is located in a JS file</u>

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

<u>ANOTHER Example where original breakpoint is moved to a new JS file</u>

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);
  }

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 2
  • Comments: 19 (5 by maintainers)

Most upvoted comments

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.

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? image 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.

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?

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.

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