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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Babel support is broken in 26.4.2 #2064

Closed
RA80533 opened this issue Oct 26, 2020 · 7 comments
Closed

Babel support is broken in 26.4.2 #2064

RA80533 opened this issue Oct 26, 2020 · 7 comments

Comments

@RA80533
Copy link

@RA80533 RA80533 commented Oct 26, 2020

馃挜 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
Copy link
Author

@RA80533 RA80533 commented Oct 26, 2020

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

const baseBabelCfg = { cwd: this.cwd }

@ahnpnl
Copy link
Collaborator

@ahnpnl ahnpnl commented Oct 26, 2020

indeed confirmed 26.4.1 works with this

ahnpnl added a commit to ahnpnl/ts-jest that referenced this issue Oct 26, 2020
ahnpnl added a commit to ahnpnl/ts-jest that referenced this issue Oct 26, 2020
ahnpnl added a commit to ahnpnl/ts-jest that referenced this issue Oct 26, 2020
@ahnpnl ahnpnl closed this in #2071 Oct 26, 2020
ahnpnl added a commit that referenced this issue Oct 26, 2020
#2071)

Closes #2064
@RA80533
Copy link
Author

@RA80533 RA80533 commented Nov 4, 2020

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

@ahnpnl ahnpnl commented Nov 4, 2020

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

@RA80533 RA80533 commented Nov 4, 2020

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

@RA80533 RA80533 commented Nov 4, 2020

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

@ahnpnl ahnpnl commented Nov 4, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants
You can鈥檛 perform that action at this time.