Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testMatch on Windows #7914

Closed
artola opened this issue Feb 16, 2019 · 23 comments
Closed

testMatch on Windows #7914

artola opened this issue Feb 16, 2019 · 23 comments

Comments

@artola
Copy link
Contributor

artola commented Feb 16, 2019

🐛 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
Copy link
Collaborator

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
Copy link
Member

SimenB commented Feb 16, 2019

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

@artola
Copy link
Contributor Author

artola commented Feb 16, 2019

@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
Copy link
Collaborator

Oh, that may be the case. Reopening then

@thymikee thymikee reopened this Feb 16, 2019
@artola
Copy link
Contributor Author

artola commented Feb 16, 2019

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
Copy link
Contributor Author

artola commented Feb 16, 2019

@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
Copy link

@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
Copy link

sheerun commented Sep 20, 2019

Can we count on fix?

@SimenB
Copy link
Member

SimenB commented Sep 20, 2019

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
Copy link
Contributor Author

artola commented Sep 20, 2019

@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
Copy link
Member

SimenB commented Sep 20, 2019

Aight, fair enough! Looking forward to that PR 😊

@shaodahong
Copy link

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

jharvey10 added a commit to jharvey10/carbon that referenced this issue Feb 14, 2020
* Updating jest `testMatch` micromatch expressions (jestjs/jest#7914)
* Replacing `/` with `path.sep` in icon-build-helpers search.js
* Replacing regex using `/` with `[\\/]` in test-utils scss.js
@karpov-kir
Copy link

karpov-kir commented Dec 10, 2021

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
Copy link

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
Copy link

ChadBailey commented Jun 3, 2022

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
Copy link

jaitjacob commented Nov 9, 2022

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
Copy link

alilland commented Feb 9, 2023

+1 still experiencing issue in feb, 2023 ☹️

@burdeasa
Copy link

burdeasa commented May 2, 2023

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",
            }
        }

kamataryo added a commit to geolonia/normalize-japanese-addresses that referenced this issue Jul 29, 2023
kamataryo pushed a commit to geolonia/normalize-japanese-addresses that referenced this issue Aug 1, 2023
* Add v2 API return type interface

* Add transform request function

* Add test for level v8

* Fix type and normalizing logic

* Windows test match fix
jestjs/jest#7914
@sbenfares
Copy link

@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 ❤️ !

mergify bot pushed a commit to projen/projen that referenced this issue May 15, 2024
Related to #3384

## Initial fix

Use the same @ pattern for @(test|src) as it was implemented for `@(spec|test)` in #1949 . It seems the current pattern used to work with Jest and micromatch on Windows but it must have been changed later and stopped working.

This comment in Jest repo explains something similar
jestjs/jest#7914 (comment)
> +(spec|test) => @(spec|test) ... from 1 or more occurrences to matches 1


## Second possible fix

On the other hand, I couldn't find any `*.spec.ts` or `*.test.ts` inside the `src` folder , but only in `tests` folder.

We could simplify the Jest pattern match from 
```json
"<rootDir>/@(test|src)/**/*(*.)@(spec|test).ts?(x)"
```
to
```json
"<rootDir>/test/**/*(*.)@(spec|test).ts?(x)"
```

I tested this last pattern and it also worked fine.

---
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Copy link

github-actions bot commented Sep 5, 2024

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.

@github-actions github-actions bot added the Stale label Sep 5, 2024
Copy link

github-actions bot commented Oct 5, 2024

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 5, 2024
Copy link

github-actions bot commented Nov 5, 2024

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests