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

TypeError thrown from 'require' statement in jest-environment-jsdom #973

Closed
jonboiser opened this issue Jan 25, 2017 · 6 comments
Closed

Comments

@jonboiser
Copy link

Issue description or question

Just starting today, my entire test suite will not run, and this error appears in the console:

TypeError:jest-environment-jsdom module throws "TypeError: require(...).evalVMScript is not a function"

this is the offending line in the stack trace.

In the console, the errors appear after the files are loaded and these "running tests in sandbox" messages:

Wallaby Console: Wed, 25 Jan 2017 21:31:20 GMT wallaby:workers Running tests in sandbox [worker #2, session #1ntxh]...

Jest CLI runs fine. Before filing this issue, #961 seemed relevant, because it is also related to node_modules resolution.

Wallaby.js configuration file

const wallabyWebpack = require('wallaby-webpack');

module.exports = (wallaby) => {
  const webpackPostprocessor = wallabyWebpack({
    resolve: {
      extensions: ['', '.js', '.jsx'],
    },
  });
  return {
    tests: [
      'src/**/*.spec.js',
      { pattern: 'tests/**/*.snap' },
    ],
    files: [
      '!src/**/*.spec.js',
      { pattern: 'src/**/*.jsx', load: false },
      { pattern: 'src/**/*.js', load: false },
    ],
    compilers: {
      '**/*.js*': wallaby.compilers.babel(),
    },
    env: {
      type: 'node',
      runner: 'node',
    },
    testFramework: 'jest',
    postProcessor: webpackPostprocessor,
    debug: true,
    bootstrap(w) {
      w.testFramework.configure({
        setupFiles: [
          './config/jestConfig.js',
        ],
        moduleFileExtensions: [
          'js',
          'jsx',
          'json',
        ],
        coverageDirectory: './coverage',
      });
    },
  };
};

Code editor or IDE name and version

Atom v1.13.1

OS name and version

OSX 10.11.6

@ArtemGovorov
Copy link
Member

I'm not sure if it's related to the issue or not, but what you're doing in your config (using webpack + node env) is not supported by wallaby.js. Try removing webpack (neither jest, not wallaby.js needs it to run your tests):

module.exports = (wallaby) => {
  return {
    tests: [
      'src/**/*.spec.js'
    ],
    files: [
      '!src/**/*.spec.js',
      { pattern: 'src/**/*.jsx', load: false },
      { pattern: 'src/**/*.js', load: false },
      { pattern: 'tests/**/*.snap' }
    ],
    compilers: {
      '**/*.js*': wallaby.compilers.babel(),
    },
    env: {
      type: 'node',
      runner: 'node',
    },
    testFramework: 'jest',
    debug: true,
    bootstrap(w) {
      w.testFramework.configure({
        setupFiles: [
          './config/jestConfig.js',
        ],
        moduleFileExtensions: [
          'js',
          'jsx',
          'json',
        ],
        coverageDirectory: './coverage',
      });
    },
  };
};

@jonboiser
Copy link
Author

I removed the postProcessor: webpackPostprocessor,(and also moved { pattern: 'tests/**/*.snap' }), like above, but still getting the error.

@ArtemGovorov
Copy link
Member

Could you please share a sample repo where I could reproduce the issue to have a look?

@jonboiser
Copy link
Author

I created a simple repo here /~https://github.com/jonboiser/wallaby-jest-problem with some instruction in the README, which seems to isolate the issue to conflicting versions of jsdom (one in the root of node_modules, and one that is a dependency of jest).

A simple fix for my project will be to remove the extra jsdom dependency, but it seems there might be a new issue in Wallaby, since I've been working with this configuration for months and have only run into this issue yesterday.

@ipostol
Copy link

ipostol commented Jan 26, 2017

Have same problem for sublime

@ArtemGovorov
Copy link
Member

ArtemGovorov commented Jan 27, 2017

Thanks for the repo! The issue is a regression from our very recent changes in the algorithms of node module resolution for the node runner. The issue is fixed and the fix is published in the latest core.

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

No branches or pull requests

3 participants