config:migrate results in error message

[Vinnl]

Issue :

When I ran with an updated ts-jest, I received a notification that my configuration was outdated, and that I could run ts-jest config:migrate to migrate it. I did, but unfortunately, the migration resulted in Jest mentioning the following configuration error:

Configuration options testMatch and testRegex cannot be used together.

Expected behavior :

Tests executing successfully, or at least the configuration still being valid.

Debug log:

Was empty.

Minimal repo :

My original configuration.

{
    "clearMocks": true,
    "transform": {
      "^.+\\.tsx?$": "ts-jest"
    },
    "testRegex": "(/lib/__tests__/.*\\.(test|spec))\\.(ts|js)$",
    "testPathIgnorePatterns": [
      "lib/__tests__/__coverage__"
    ],
    "moduleFileExtensions": [
      "ts",
      "js"
    ],
    "collectCoverage": true,
    "collectCoverageFrom": [
      "lib/**/*.{js,ts}",
      "!lib/**/*.d.ts",
      "!lib/interfaces/**"
    ],
    "coveragePathIgnorePatterns": [
      "lib/__tests__/__coverage__",
      "lib/lambda/getUploadUrl.ts"
    ],
    "coverageReporters": [
      "json",
      "lcov",
      "text",
      "text-summary"
    ],
    "coverageDirectory": "lib/__tests__/__coverage__",
    "coverageThreshold": {
      "global": {
        "branches": 100,
        "functions": 100,
        "lines": 100,
        "statements": 100
      }
    },
    "globals": {
      "ts-jest": {
        "tsConfig": "lib/tsconfig.json"
      }
    }
  }

Configuration after migration

{
    "clearMocks": true,
    "testRegex": "(/lib/__tests__/.*\\.(test|spec))\\.(ts|js)$",
    "testPathIgnorePatterns": [
      "lib/__tests__/__coverage__"
    ],
    "moduleFileExtensions": [
      "js",
      "ts"
    ],
    "collectCoverage": true,
    "collectCoverageFrom": [
      "lib/**/*.{js,ts}",
      "!lib/**/*.d.ts",
      "!lib/interfaces/**"
    ],
    "coveragePathIgnorePatterns": [
      "lib/__tests__/__coverage__",
      "lib/lambda/getUploadUrl.ts"
    ],
    "coverageReporters": [
      "json",
      "lcov",
      "text",
      "text-summary"
    ],
    "coverageDirectory": "lib/__tests__/__coverage__",
    "coverageThreshold": {
      "global": {
        "branches": 100,
        "functions": 100,
        "lines": 100,
        "statements": 100
      }
    },
    "globals": {
      "ts-jest": {
        "tsConfig": "lib/tsconfig.json"
      }
    },
    "preset": "ts-jest"
  }

The diff:

   "jest": {
     "clearMocks": true,
-    "transform": {
-      "^.+\\.tsx?$": "ts-jest"
-    },
     "testRegex": "(/lib/__tests__/.*\\.(test|spec))\\.(ts|js)$",
     "testPathIgnorePatterns": [
       "lib/__tests__/__coverage__"
     ],
     "moduleFileExtensions": [
-      "ts",
-      "js"
+      "js",
+      "ts"
     ],
     "collectCoverage": true,
     "collectCoverageFrom": [
@@ -60,9 +57,10 @@
     },
     "globals": {
       "ts-jest": {
-        "tsConfigFile": "lib/tsconfig.json"
+        "tsConfig": "lib/tsconfig.json"
       }
-    }
+    },
+    "preset": "ts-jest"
   },

As you can see, I don't use the testMatch option anyway - I suppose the preset has it somewhere? If so, the migration tool should probably do something with the existing option? Unfortunately, I couldn't transform testRegex to testMatch myself, because Jest could no longer find my tests, so I'm not sure what the solution should be.

[huafu]

@Vinnl thanks for reporting! The ts-jest uses testMatch since jest uses this as the default method to match test files. I guess this issue should be a doc issue.

To fix this, you need to set testMatch to null as the preset can't know what's you're overriding later on. I'm going to update the issue title so that it's related to doc.

Update: This should also be mentioned in the doc when using preset.

[Vinnl]

Ehm wow, that was ridiculously fast - I was still working on the formatting of the issue. But thanks, setting testMatch to null solves it! Wouldn't the solution then be to have the migration tool set it to null as well when testRegex is present?

[huafu]

Was updating while I got your answer hehe!