vscode 1.32.1 jest debug cannot find test files specified if running from current file

[sativ01]

• VSCode Version: 1.32.1
• OS Version: Win 7

Steps to Reproduce:

1. launch config file:

{
      "type": "node",
      "request": "launch",
      "name": "Jest Current File",
      "program": "${workspaceFolder}/node_modules/.bin/jest",
      "args": [
        "${relativeFile}",
        "--config",
        "${workspaceFolder}/tests/jest.config.js"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "disableOptimisticBPs": true,
      "windows": {
        "program": "${workspaceFolder}/node_modules/jest/bin/jest",
      }
    }

2. Open file that you want to test, e.g. Component.spec.jsx and run the above launch configuration
3. Output:

Debugger listening on ws://127.0.0.1:21033/...
For help see https://nodejs.org/en/docs/inspector
Debugger attached.
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In C:\nextgen\ng\ui\common.ui
  171 files checked.
  testMatch: C:/nextgen/ng/ui/common.ui/utils/**/*.spec.(es6|jsx),C:/nextgen/ng/ui/common.ui/components/**/*.spec.(es6|jsx) - 33 matches
  testPathIgnorePatterns: \\node_modules\\ - 171 matches
  testRegex:  - 171 matches
Pattern: components\form\__tests__\DateTimePicker.spec.jsx - 0 matches
Waiting for the debugger to disconnect...

Does this issue occur when all extensions are disabled?: Yes

It works fine with previous version of VS Code

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Stepping through code with debugger not showing other file (#68106)

[sla89]

I have the same issue.

[weinand]

Does it work with the latest Insiders?

[bcanseco]

Can confirm this is happening on a fresh install of latest Insiders using jest@24.1.0.

$ G:\repro  cd 'g:\repro'; & 'C:\Program Files\nodejs\node.exe' '--inspect-brk=11706' 'node_modules\jest\bin\jest.js' 'src\services\jwt\index.spec.js'
Debugger listening on ws://127.0.0.1:11706/1758821f-a2fa-4350-8e4e-22e1abf0d8f9
For help see https://nodejs.org/en/docs/inspector
Debugger attached.
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In G:\repro
  192 files checked.
  testMatch: **/__tests__/**/*.[jt]s?(x),**/?(*.)+(spec|test).[tj]s?(x) - 6 matches
  testPathIgnorePatterns: node_modules,.cache - 110 matches
  testRegex:  - 192 matches
Pattern: src\services\jwt\index.spec.js - 0 matches
Waiting for the debugger to disconnect...

[phil-scott-78]

Seeing the same thing. Looks like this is a regression of #40256 with ${relativeFile} using windows style slashes. That's why jest can't find the file. I haven't been using jest that long but it does seem like they also introduced a new parsing for testMatch that is less forgiving in a recent version per this issue jestjs/jest#7914. So maybe this regression wasn't caught until this update with jest.

[isidorn]

I confirm that there seems to be a breakage with ${relativeFile} to use win specific slashes on windows.
This is a regression.
My win VM is dog slow for some reason and I did not make any changes in this area. @alexr00 could you maybe investigate a bit, you also know the configurationResolverService?
@aeschli did you change something in this area with your path refactorings?

code pointer https://github.com/Microsoft/vscode/blob/04dbcafd35fd8de4ed4bd66022c0bba67a10dac7/src/vs/workbench/services/configurationResolver/common/variableResolver.ts#L175

[isidorn]

After investigating with @alexr00 and @weinand we do confirm that the ${relativeFile} behavior has changed in vscode.
Now ${relativeFile} is consistent with all other predefined variables in that it returns platform specific separators. Forward slash on mac and linux and backslash on windows.
@phil-scott-78 thanks for digging out #40256 which basically contains this discussion.

${relativeFile} should behave like all other variables and due to that I am closing this as designed.

Please file this bug against Jest that it should hande backslashes on windows.

As a workaround instead of using ${relativeFile} I suggest to type in the path up to the filename. So a/b/c.txt, instead of using ${relativeFIle} use a/b/${fileBasename}. That way the arg will be based on the currently opened file.

We should have announced this change in the release notes and we appologise that we did not.

[pbricout]

@isidorn In my case I can't your proposed solution of hardcoding the path, because the path can change based on the selected file.
I use bash in my scripts and on Windows I now receive abcfile instead a/b/c/file.
The tasks.json and script is shared for both Windows and Linux platform.
What solution do you propose to handle this kind of situation?
If I could at least receive a string like a\b\c\file I could handle it in the script, but when I receive abcfile there is nothing I can do.
This topic has been discussed in the many issues already. I would be keen to find a solution could work what the shell or command is specified in the task.json or other places where these variables are used.
A parameter somewhere? It has been suggested in the some issues to have something generic in the variable ${variable:something}.
Thanks
This is following this issue I created:
#70926

[pbricout]

@isidorn I finally found a clean solution to this problem. I agree that the path format for the variables should be consistent and inline with the platform.
My problem, on Windows, was that when using something like ${relativeFile} as an argument in a task with something like that:

{
    "label": "Task",
    "type": "shell",
    "command": "myScript",
    "args": [
        "${relativeFile}"
    ]
}

the backslashes were interpreted as escape characters rather being part of the string, the script was seeing the argument $1 as abc rather than a\b\c.
To prevent this from happening, the variable need to be between quotes when passed as an argument, i.e. in the task file:

{
    "label": "Task",
    "type": "shell",
    "command": "myScript",
    "args": [
        "\"${relativeFile}\""
    ]
}

Then in my script when I receive the parameters I can transform all the back slashes in forward slashes with a variable replacement, something like in bash:

relativeFile=${1//\\/\/}"

So far this seems to work nicely and my make tasks.json and scripts compatible for both Windows and Unix platforms.

[fxlemire]

${relativeFile} should behave like all other variables and due to that I am closing this as designed.

This however breaks the WSL use case. Is there a way, when useWSL: true, to specify using forward slashes?

[fxlemire]

I forgot to add my workaround for anyone who needs it.

Basically, replace ${relativeFile} with your relative constant test path, and then add an input so you can type in the desired dynamic path.

For example, if all of your test files are under src/test:

{
  configurations: [
    {
      // ... test launch config
      "args": [
        // ... desired args
       "src/test/${input:testPath}" // instead of "${relativeFile}"
      ]
    }
  ],
  "inputs": [
    {
      "id": "testPath",
      "description": "Please enter a test path",
      "default": "", // wish we could add ${fileBasename} here but seems like it's impossible
      "type": "promptString"
    }
  ]
}

But I do hope this can stay as a workaround, and that useWSL or some other config will allow to force the path to be with forward slashes 🙏