Babel support is broken in 26.4.2

[RA80533]

💥 Regression Report

PR #2020 introduced a breaking change related to how Babel configuration is loaded. Previously, Babel configuration was loaded via the babelConfig option.

Last working version

Worked up to version: 26.4.1

Stopped working in version: 26.4.2

To Reproduce

Steps to reproduce the behavior:

• Have a valid .babelrc file at the root directory of the project
• Define rootDir as the root directory of the project

{
  …
  "globals": {
    "ts-jest": {
      "babelConfig": "<rootDir>/.babelrc"
    }
  },
  "rootDir": "./",
  …
}

$ yarn jest
yarn run v1.22.10
$ /Users/RA80533/lightning-banana/node_modules/.bin/jest
 FAIL   lightning-banana  src/index.spec.ts
  ● Test suite failed to run

    ENOENT: no such file or directory, open '<rootDir>/.babelrc'

      at ConfigSet._setupTsJestCfg (../../node_modules/ts-jest/dist/config/config-set.js:176:95)
      at new ConfigSet (../../node_modules/ts-jest/dist/config/config-set.js:152:14)
      at TsJestTransformer.createOrResolveTransformerCfg (../../node_modules/ts-jest/dist/ts-jest-transformer.js:95:38)
      at TsJestTransformer.getCacheKey (../../node_modules/ts-jest/dist/ts-jest-transformer.js:72:14)
      at ScriptTransformer._getCacheKey (../../node_modules/@jest/transform/build/ScriptTransformer.js:255:23)
      at ScriptTransformer._getFileCachePath (../../node_modules/@jest/transform/build/ScriptTransformer.js:289:27)
      at ScriptTransformer.transformSource (../../node_modules/@jest/transform/build/ScriptTransformer.js:428:32)
      at ScriptTransformer._transformAndBuildScript (../../node_modules/@jest/transform/build/ScriptTransformer.js:568:40)

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        0.398 s
Ran all test suites.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Expected behavior

babelConfig should be read.

[RA80533]

At the very least, Babel configuration should be loaded from the same directory as the Jest configuration. It appears rootDir is interpreted as being at the top-most directory of the project just inside the scope of the options passed to the "ts-jest" object. In other words:

/// @file lightning-banana/packages/common/jest.config.json
{
  "globals": {
    "ts-jest": {
      /// Resolved to "lightning-banana/.babelrc"
      /// Expected to resolve to "lightning-banana/packages/common/.babelrc"
      "babelConfig": "<rootDir>/.babelrc"
    }
  },
  "roots": [
    /// Resolved to "lightning-banana/packages/common/src"
    "<rootDir>/src"
  ],
  "setupFilesAfterEnv": [
    /// Resolved to "lightning-banana/packages/common/jest.setup.js"
    "<rootDir>/jest.setup.js"
  ]
}

ts-jest/src/config/config-set.ts

Line 220 in a93fff1

const baseBabelCfg = { cwd: this.cwd }

[ahnpnl]

indeed confirmed 26.4.1 works with this

[RA80533]

/cc @ahnpnl

There still seems to be an issue with loading Babel-related files. Setting babelConfig to true does not seem to look for files in the correct directory. Rather than looking in the same directory as the configuring tsconfig.json file, ts-jest looks for files in the current working directory.

[ahnpnl]

@RA80533 I checked the codes in 26.4.1 and that is also the case. When babelConfig: true, ts-jest will return babel config option which is

{
     cwd: this.cwd
}

after that babel-jest will find the config itself.

[RA80533]

I've isolated the issue to my use of Yarn workspaces:

• yarn workspaces run jest produces an issue in the workspace relying on Babel
• yarn workspace ${child} run jest configures Babel with the file in the directory of child

To be clear, the parent directory does not contain any Babel-related files whereas child does.

@ahnpnl I suppose this isn't a regression issue then.

[RA80533]

/cc @ahnpnl

Prior to its change in commit a0e5639 (see lines 186–195 of config-set.ts), Babel configuration was handled correctly in commit dee15ff (see lines 264–265 of config-set.ts):

// babel config (for babel-jest) default is undefined so we don't need to have fallback like tsConfig or packageJson
const babelConfig: TsJestConfig['babelConfig'] = this.getInlineOrFileConfigOpt(options.babelConfig)

/**
 * @internal
 */
private getInlineOrFileConfigOpt(
  configOpt: string | boolean | Record<string, any> | undefined,
): { kind: 'inline' | 'file'; value: any } | undefined {
  if (typeof configOpt === 'string' || configOpt === true) {
    return {
      kind: 'file',
      value: typeof configOpt === 'string' ? this.resolvePath(configOpt) : undefined,
    }
  } else if (typeof configOpt === 'object') {
    return {
      kind: 'inline',
      value: configOpt,
    }
  }

  return
}

resolvePath(
  inputPath: string,
  { throwIfMissing = true, nodeResolve = false }: { throwIfMissing?: boolean; nodeResolve?: boolean } = {},
): string {
  let path: string = inputPath
  let nodeResolved = false
  if (path.startsWith('<rootDir>')) {
    path = resolve(join(this._rootDir, path.substr(9)))
  } else if (!isAbsolute(path)) {
    if (!path.startsWith('.') && nodeResolve) {
      try {
        path = require.resolve(path)
        nodeResolved = true
      } catch (_) {}
    }
    if (!nodeResolved) {
      path = resolve(this.cwd, path)
    }
  }
  if (!nodeResolved && nodeResolve) {
    try {
      path = require.resolve(path)
      nodeResolved = true
    } catch (_) {}
  }
  if (throwIfMissing && !existsSync(path)) {
    throw new Error(interpolate(Errors.FileNotFound, { inputPath, resolvedPath: path }))
  }

  this.logger.debug({ fromPath: inputPath, toPath: path }, 'resolved path from', inputPath, 'to', path)

  return path
}

[ahnpnl]

In the scenario of babelConfig: true, the old codes will return

return {
      kind: 'file',
      value: undefined,
}

which is then go to this https://github.com/kulshekhar/ts-jest/blob/v26.4.1/src/config/config-set.ts#L378 . Because value is undefined, neither if path or else if path will execute, which will then return https://github.com/kulshekhar/ts-jest/blob/v26.4.1/src/config/config-set.ts#L398 and the final result is

{
    cwd: this.cwd
}

and for the refactored codes, the scenario babelConfig: true will end up here https://github.com/kulshekhar/ts-jest/blob/master/src/config/config-set.ts#L237

So both old codes and refactored codes are the same.