testMatch on Windows

[artola]

🐛 Bug Report

The following testMatch works on unix systems while does not on Windows machines. It is required to narrow the folders where to look for tests.

  testMatch: [
    '<rootDir>/src/**/?(*.)+(spec|test).(ts|tsx|mjs|js|jsx)',
  ],

Error on Windows:

  636 files checked.
  testMatch: C:/Users/IEUser/Fusion-UI/packages/infodesk/src/**\?(*.)+(spec|test).(ts|tsx|mjs|js|jsx) - 0 matches
  testPathIgnorePatterns: \\node_modules\\ - 636 matches
  testRegex:  - 636 matches
Pattern:  - 0 matches
error Command failed with exit code 1.

To Reproduce

Set a testMatch that starts with <rootDir>/src/... in place of the default **/*/....
See in the error message src/**\?(*.) here the / was replaced by \ and it is a lonely case.

Expected behavior

testMatch should work cross OS as in v23.

Link to repl or repo (highly encouraged)

this repro work in v22 while fails in v24 with Windows: https://repl.it/@artola/jest-bug

Run npx envinfo --preset jest

Paste the results here:

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
  Binaries:
    Node: 11.9.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.5.0 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.1.0 => 24.1.0 

[thymikee]

We moved to micromatch@3 and it seems like your glib is not valid anymore. You'll need to adjust it to be compliant. We're sorry this happens but it was announced as a breaking change

[SimenB]

I wonder if this is #7814? Seeing as OP says it works on unix

[artola]

@thymikee I know about the breaking change and we changed the glob, mainly I just use the default one shown in jest --init with the prefix <rootDir>/src/. While this works on Mac/Unix, does not on Windows.

[thymikee]

Oh, that may be the case. Reopening then

[artola]

I wonder if this is #7814? Seeing as OP says it works on unix

@SimenB I am using v24.1 but if I add the slash wrapper as shown here (https://github.com/facebook/jest/blob/d81c4cb5443e529a5c0572e5b9e4f231249c3609/packages/jest-config/src/utils.js#L70) the testMatch works on unix and also on Windows.

[artola]

@SimenB @thymikee When I create a config using jest --init shows this block:

  // The glob patterns Jest uses to detect test files
  // testMatch: [
  //   "**/__tests__/**/*.[jt]s?(x)",
  //   "**/?(*.)+(spec|test).[tj]s?(x)"
  // ],

Then I just uncommented this block and tweaked a bit to support <rootDir>/src/.
This change does not play well in Windows while in Unix is ok as reported above.

Now what I did is slightly change the glob and works in both OS, following the doc in micromatch.

  // The glob patterns Jest uses to detect test files
  testMatch: [
     "<rootDir>/src/**/__tests__/**/*.[jt]s?(x)",
     "<rootDir>/src/**/*(*.)@(spec|test).[tj]s?(x)"
  ],

Here the more important changes:

• ?(*.) => *(*.) ... from 0 or 1 occurrence to 0 or more occurrences
• +(spec|test) => @(spec|test) ... from 1 or more occurrences to matches 1

Could be that "just" the default for testMatch shown in the documentation need some update?

[AndrewCraswell]

@artola That solves my issues after upgrading multiple of my projects to latest Jest. Befeorehand I had to add a bunch of ignore entries to stop it from picking up files that Jest thought had tests but didn't actually, resulting in fake fails. One such example is the Create React App's test.js script which actually executes Jest.

[sheerun]

Can we count on fix?

[SimenB]

Not sure what a fix would be? Is it a documentation or implementation issue? A PR for either is very much welcome as none on the core team uses windows. We do test windows on CI though, so if it's a code issue we can add a test as well

[artola]

@SimenB It is a code issue, see my comment above, a solution is wrap this return with slash.

https://github.com/facebook/jest/blob/16930281c466ef3ac7a07d9777d47b2d208ce16e/packages/jest-config/src/utils.ts#L66

It will be great if some Windows expert verifies and creates the PR.

In the meantime the solution was change the micromatch as explained.

[SimenB]

Aight, fair enough! Looking forward to that PR 😊

[shaodahong]

yup, the focus is the path slash

In windows default slash like tests\rules\indent\indent.test.ts, but jest does not match this, must change like tests/rules/indent/indent.test.ts

[karpov-kir]

Hello!

I encountered a similar issue. The following wildcard works on Unix machines but does not work on Windows machines:

'<rootDir>/packages/**/(src|test)/**/*.(test|spec|e2e-spec).*'

@SimenB, after some debugging I found that there is replacePathSepForGlob function in jest-utils which is used in parsing of config files.

Here is this function:

// node_modules/jest-util/build/replacePathSepForGlob.js

function replacePathSepForGlob(path) {
  return path.replace(/\\(?![{}()+?.^$])/g, '/');
}

I changed it to log the result and path:

function replacePathSepForGlob(path) {
  const result =  path.replace(/\\(?![{}()+?.^$])/g, '/');
  console.log('Replace sep for glob', {path, result})
  return result
}

So, the issue happens because this function converts glob patents on Windows machines in the following way:

Wildcard: '<rootDir>/packages/**/(tests|src)/**/*.(test|spec|e2e-spec).*'
Path: 'C:\\Users\\user\\Documents\\project\\packages\\**\\(src|test)\\**\\*.(test|spec|e2e-spec).*',
Replaced path: 'C:/Users/user/Documents/project/packages/**\\(src|test)/**/*.(test|spec|e2e-spec).*'

The issue is in this place (in replaced part) .../packages/**\\(src|test)/**/... - double slash is not replaced with a singular slash to be .../packages/**/(src|test)/**/....

It looks like ecranisation logic conflicts with double backslashes. So, if / is followed by (a|b) wildcard on Windows then the replaced path is incorrect.

Additional notes:

• /+(a|b) wildcard (with modificator prefix) does not work
• /(a|b) wildcard (without modificator prefix) works well if you try it e.g. here: https://globster.xyz/
• /(a|b) wildcard (without modificator prefix) works on Unix machines
• /{a..b} (braces) does not work, e.g.:

Wildcard: '<rootDir>/packages/**/{1..3}/**/*.(test|spec|e2e-spec).*'
Path: 'C:\\Users\\user\\Documents\\project\\packages\\**\\{1..3}\\**\\*.(test|spec|e2e-spec).*',
Replaced path: 'C:/Users/user/Documents/project/packages/**\\{1..3}/**/*.(test|spec|e2e-spec).*'

Am I missing something? Or there is an issue?

---

In my case, I found only one workaround for /(a|b) wildcard. Such wildcard can be split into multiple wildcards:

testMatch: [
   '<rootDir>/packages/**/(tests|src)/**/*.(test|spec|e2e-spec).*'
  ],

change to

testMatch: [
    '<rootDir>/packages/**/tests/**/*.(test|spec|e2e-spec).*',
    '<rootDir>/packages/**/src/**/*.(test|spec|e2e-spec).*',
  ],

[yichi-yang]

We do test windows on CI though

@SimenB correct me if I'm wrong, the test uses path.posix on Windows, so it doesn't behave the same as require('path') on Windows (should be path.win32 on Windows by default).

https://github.com/facebook/jest/blob/abca0fe6c1d9fed884e4dc8bb911b3497db506ee/packages/jest-config/src/__tests__/normalize.test.ts#L21

I want to take a stab at fixing this, but writing a separate test suite for Windows seems like a lot of work to me.

[ChadBailey]

edit: sigh I'm guessing I had some other botched config leading up to the issue I reported, as I've started over and am no longer experiencing the behavior I reported.

[jaitjacob]

This issue persists. I was able to reproduce this issue on Jest version 28.1.3 installed on Windows Version 10.0.22621. My testMatch option is defined as, testMatch: ['/**/*.test.*(/ts|/tsx)'] within jest.config.js.

The message I get when I run Jest is,

No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In C:\Users\jaitj\Documents\osc\chapter
  432 files checked.
  testMatch: /**/*.test.(ts|tsx) - 0 matches
  testPathIgnorePatterns: \\node_modules\\ - 432 matches
  testRegex:  - 0 matches
Pattern:  - 0 matches

The path separators for testMatch & testPathIgnorePatterns in the message above stand out to me. I wonder what makes Jest internally translate the path separator correctly for testPathIgnorePatterns but NOT for testMatch. The former option is defined as watchPathIgnorePatterns: ['/node_modules'] in jest.config.js.

[alilland]

+1 still experiencing issue in feb, 2023 ☹️

[burdeasa]

One possible workaround when trying to get a launch.json file to work on Windows is to use this VSCode extension:
https://marketplace.visualstudio.com/items?itemName=rioj7.command-variable

I installed this, and then used the following launch.json configuration:

        {
            "name": "Debug One Test File",
            "type": "node",
            "request": "launch",
            "runtimeArgs": [
                "--inspect-brk",
                "${workspaceRoot}/node_modules/jest/bin/jest.js",
                "--runInBand",
                "${command:extension.commandvariable.file.relativeFilePosix}"
            ],
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "env": {
                "JEST_TEST_TIMEOUT": "2147483647",
            }
        }

[sbenfares]

@SimenB @thymikee When I create a config using jest --init shows this block:

  // The glob patterns Jest uses to detect test files
  // testMatch: [
  //   "**/__tests__/**/*.[jt]s?(x)",
  //   "**/?(*.)+(spec|test).[tj]s?(x)"
  // ],

Then I just uncommented this block and tweaked a bit to support <rootDir>/src/. This change does not play well in Windows while in Unix is ok as reported above.

Now what I did is slightly change the glob and works in both OS, following the doc in micromatch.

  // The glob patterns Jest uses to detect test files
  testMatch: [
     "<rootDir>/src/**/__tests__/**/*.[jt]s?(x)",
     "<rootDir>/src/**/*(*.)@(spec|test).[tj]s?(x)"
  ],

Here the more important changes:

• ?(*.) => *(*.) ... from 0 or 1 occurrence to 0 or more occurrences
• +(spec|test) => @(spec|test) ... from 1 or more occurrences to matches 1

Could be that "just" the default for testMatch shown in the documentation need some update?

Thanks, your workaround worked for me on Windows 11 ❤️ !

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.