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

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

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