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

getVersion is not defined #7704

Closed
hediet opened this issue Jan 25, 2019 · 37 comments · Fixed by #7707
Closed

getVersion is not defined #7704

hediet opened this issue Jan 25, 2019 · 37 comments · Fixed by #7707
Labels

Comments

@hediet
Copy link

hediet commented Jan 25, 2019

🐛 Bug Report

Jest v24 crashes with "getVersion" is not defined.

To Reproduce

See source code.

Expected behavior

Jest does not crash.

Issue in source

This line requires cli.
But cli itself requires jest here. Clearly, getVersion is not exported at this point.

Run npx envinfo --preset jest

Paste the results here:

System:
    OS: Windows 10
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  Binaries:
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD
@rubennorte
Copy link
Contributor

I can't repro the error. Can you share what you executed when it crashed?

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

Not sure what's happening, but one thing that's bitten me before is mismatching jest installations.

Make sure to not have both jest and jest-cli installed at the same time (you just need jest), and that you're not using CRA (CRA ships with its own version of Jest, so you shouldn't update it yourself 🙂)

@hediet
Copy link
Author

hediet commented Jan 25, 2019

Our setup is somewhat complex, I basically ran jest --config our-config.js, and our-config.js loads typescript using ts-node, I can try to further simplify that to understand where the issue comes from.

But regardless of how I ran it and what my setup is, why should it work at all? What breaks the cyclic reference between jest.js and cli/index.js?

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

getVersion is a function (which is not invoked until later), and node handles cyclic requires

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

I 100% agree it's not ideal, of course 🙂

@hediet
Copy link
Author

hediet commented Jan 25, 2019

@SimenB stepping through the transpiled code, it seems like nodejs is first executing jest/jest.js until there:

'use strict';

var _package = require('../package.json');

var _SearchSource = _interopRequireDefault(require('./SearchSource'));

var _TestScheduler = _interopRequireDefault(require('./TestScheduler'));

var _TestWatcher = _interopRequireDefault(require('./TestWatcher'));

var _cli = require('./cli'); // === here ===

function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : {default: obj};
}
/**
 * Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 *
 *
 */
// === this is not executed yet ===
module.exports = {
  SearchSource: _SearchSource.default,
  TestScheduler: _TestScheduler.default,
  TestWatcher: _TestWatcher.default,
  getVersion: () => _package.version,
  run: _cli.run,
  runCLI: _cli.runCLI
};

Where it then descends into jest/cli/index.js:

function _asyncToGenerator(fn) {
  return function() {
    var self = this,
      args = arguments;
    return new Promise(function(resolve, reject) {
      var gen = fn.apply(self, args);
      function _next(value) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, 'next', value);
      }
      function _throw(err) {
        asyncGeneratorStep(gen, resolve, reject, _next, _throw, 'throw', err);
      }
      _next(undefined);
    });
  };
}
const _require = require('../jest'),
  getVersion = _require.getVersion;
// === at this point, `_require` equals `{}`, so getVersion is undefined. ===
function run(_x, _x2) {
  return _run2.apply(this, arguments);
}

Clearly, here, it then crashes:

const buildArgv = (maybeArgv, project) => {

  const version =
    getVersion() + // === getVersion is still undefined ===
    (__dirname.includes(`packages${_path().default.sep}jest-cli`)
      ? '-dev'
      : '');
// [...]

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

Not sure what's going on - I'm unable to reproduce.

$ mkdir 24
$ cd 24
$ yarn init -y
# ...
$ yarn add jest
# ...
$ yarn jest --version
yarn run v1.13.0
$ /Users/simen/24/node_modules/.bin/jest --version
24.0.0

So a reproduction would be awesome!

It might very well be that ts-node is somewhat buggy and doesn't work in the same way node does. Why do you need ts-node?

@hediet
Copy link
Author

hediet commented Jan 25, 2019

We need ts-node because our configuration is written in typescript. I try to make it reproducible.
But clearly there is an issue in the transpiled source, isn't it?

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

However, installing ts-node still works

$ yarn add ts-node typescript
$ npx ts-node node_modules/.bin/jest --version
24.0.0

@hediet
Copy link
Author

hediet commented Jan 25, 2019

Further debugging showed that the issue is the order in which the modules are loaded. If jest/cli/index is loaded first, everything works. If jest/jest.js is loaded first, it crashes due to the described reasons. I am currently investigating why jest/jest.js is loaded before jest/cli/index in our setup.

Anyways, code should not break if it is loaded in a different order than the default case, especially if the order is up to the caller of the API.

@jeysal
Copy link
Contributor

jeysal commented Jan 25, 2019

For reference: Whatever the circumstances this appears under may be, reason why it started showing in v24 is this PR.

@eliw00d
Copy link

eliw00d commented Jan 25, 2019

I'm running into this same error but only when running jest programmatically (require('jest').run(argv)). When I yarn jest it works fine.

@hediet
Copy link
Author

hediet commented Jan 25, 2019

I'm running into this same error but only when running jest programmatically (require('jest').run(argv)). When I yarn jest it works fine.

Thank you, we also run it programmatically. That seems to be it.

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

Ah, ok. We need #7696 😅

I'll put together a PR

@hediet
Copy link
Author

hediet commented Jan 25, 2019

@SimenB thank you for your help :)

@eliw00d
Copy link

eliw00d commented Jan 25, 2019

@SimenB Is there a workaround for 24 or is this likely something we won't see until 25 or 24.1?

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

#7707 fixes this issue. #7696 will probably land soonish, proper programmatic API... I don't know. Maybe 25? 🙂 I'll open up an issue for it requesting feedback

@eliw00d
Copy link

eliw00d commented Jan 25, 2019

Sounds good. Thanks!

@jeysal
Copy link
Contributor

jeysal commented Jan 25, 2019

Does anyone know why it breaks when running it like that though? Don't think I've seen something like this happening because of cyclic dependencies before

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

It breaks when build/jest is loaded first, not build/cli/index

@hediet
Copy link
Author

hediet commented Jan 25, 2019

@jeysal see my in-detail explanation above what happens and why it breaks. require loads modules if they have not been cached before (i.e. loaded before) and creates an empty cache object for it, otherwise they use the cached module.
So cyclic require calls are handled without indefinitely recursing, but module could be empty as in this case.

@jeysal
Copy link
Contributor

jeysal commented Jan 25, 2019

Oh I see now...
Looks like this happened because #7582 landed after the short-lived ESM migration (#7548) and it had to be converted to CommonJS in #7602, which it wasn't really compatible with
https://github.com/facebook/jest/pull/7602/files#diff-281a28872bb5a78b747f7cd3d114a0ed

@SimenB
Copy link
Member

SimenB commented Jan 25, 2019

@eliw00d @hediet workaround before new release:

// Preload `cli` to avoid cyclical dependency
require('jest-cli/build/cli');

require('jest').run(...);

@bricss
Copy link

bricss commented Jan 28, 2019

@SimenB it doesn't even work with a workaround 😢

> node scripts/test.js

TypeError: getVersion is not a function
    at buildArgv (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:399:5)
    at Object.<anonymous> (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:243:20)
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:202:24)
    at _next (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:222:9)
    at ~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:227:7
    at new Promise (<anonymous>)
    at Object.<anonymous> (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:219:12)
    at Object._run2 (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:265:16)
    at Object.run (~\node_modules\jest\node_modules\jest-cli\build\cli\index.js:236:16)

@eliw00d
Copy link

eliw00d commented Jan 28, 2019

Weird. The workaround worked fine for me.

@SimenB
Copy link
Member

SimenB commented Jan 28, 2019

@bricss what does scripts/test.js look like?

@bricss
Copy link

bricss commented Jan 28, 2019

@SimenB technically, as I know, it was created by create-react-app version ~2.x.x, and never touched by anyone.

P.S.: Node.js - v11.8.0 is used.

@SimenB
Copy link
Member

SimenB commented Jan 28, 2019

How are you applying the workaround then, if you haven't updated the file?

@bricss
Copy link

bricss commented Jan 28, 2019

@SimenB I meant it wasn't touched by anyone before me. I placed imports exact in same order as was suggested.

@yordis
Copy link
Contributor

yordis commented Jan 28, 2019

Hey @SimenB, is this released as part of 24.0.0 #7707 ?

Also, I can confirm that #7704 (comment) worked for me

@jeysal
Copy link
Contributor

jeysal commented Jan 28, 2019

The fix #7707 is not yet released.

@bricss
Copy link

bricss commented Jan 28, 2019

I kinda don't wanna rush anyone, but maybe it's time to let it go with version 24.0.1 🛸

bencode added a commit to bencode/react-test-mate that referenced this issue Jan 29, 2019
@bricss
Copy link

bricss commented Jan 29, 2019

Battlefield news: 📰

I have managed to start Jest by adding those lines into the scripts/test.js:

// jest v24.0 workaround
require('jest/node_modules/jest-cli/build/cli');
require('jest').run(argv);

After, when I'm start Jest to run all over the tests, it shows this:

No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In C:\<projectPath>
  49 files checked.
  testMatch: <projectPath>/src/**\?(*.)(spec|test).{js,jsx,ts,tsx} - 0 matches
  testPathIgnorePatterns: \\node_modules\\ - 49 matches
  testRegex:  - 49 matches
Pattern:  - 0 matches

Unable to locate any of the test files. 🔍

@shabbyrobe
Copy link

I had the same experience as @bricss. require('jest-cli/build/cli'); did not work for me, but require('jest/node_modules/jest-cli/build/cli'); did. Former CRA app, latest version, ejected quite recently.

@nonjene
Copy link

nonjene commented Feb 3, 2019

To break the dependency cycle, we can delete the module cache and require it again

in scripts/test.js:

delete require.cache[require.resolve('jest-cli/build/cli/index.js')];
const cli = require('jest-cli/build/cli/index.js');

@jeysal
Copy link
Contributor

jeysal commented Feb 5, 2019

24.1.0 is released

riesinger added a commit to freecloudio/web that referenced this issue Mar 4, 2019
The workaround was needed because jest 24.0 had a dependency cycle and
therefore was problematic to import and use programatically.
See jestjs/jest#7704.

This closes #25.
GoPro16 added a commit to Availity/availity-workflow that referenced this issue Sep 27, 2019
GoPro16 added a commit to Availity/availity-workflow that referenced this issue Sep 27, 2019
@github-actions
Copy link

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 May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants