Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[BUG] rimraf causes failure with multiple browsers on Windows

See original GitHub issue

Context:

PlayWright Version: 0.10.0
Operating System: Windows 2019

Might relate to #680

Code Snippet

Run npx jest

const { chromium } = require("playwright");

test("browser one success", async () => {
  const context = await chromium.launch();
  await context.close();
});

test("browser two failure", async () => {
  const context = await chromium.launch();
  await context.close();
});

Describe the bug

The second test throws this error.

assert(received)

    Expected value to be equal to:
      true
    Received:
      false

      at fixWinEPERM (node_modules/rimraf/rimraf.js:175:5)
      at node_modules/rimraf/rimraf.js:160:15

Others have seen this same issue with rimraf on windows. https://github.com/facebook/jest/issues/3942#issuecomment-313169747 https://github.com/GoogleChrome/lighthouse/pull/2641

I tried to force the playwright-core resolution to rimraf 3.0.1 but I ran into the same issue.

Is there a way to remove the rimraf dependency and replace it with fs-extra, that seems to be an approach that worked here. https://github.com/getgauge/taiko/issues/837

Issue Analytics

State:
Created 4 years ago
Reactions:2
Comments:8 (8 by maintainers)

Top GitHub Comments

4reactions

aslushnikovcommented, Feb 4, 2020

Once/if https://github.com/isaacs/rimraf/pull/209 is merged and a new version is released, we can roll the dependency. It’ll fix this bug.

We’ll probably wait for a week to see if we can land the fix to rimraf. If there’s a delay, we can detect jest environment and provide rimraf with custom fs hooks that re-throw vm-native errors

const isJestEnvironment = (function() {
  try {
    some_undefined_variable_goes_here;
  } catch (e) {
    return !(e instanceof  Error);
  }
})();

3reactions

aslushnikovcommented, Feb 4, 2020

Ok, we now know what’s going on!

Investigation

Jest runs tests in separate VMs (or execution contexts).
For every VM, Jest creates a test environment: this defaults to JSDOMEnvironment. JSDOM’s global is then used as VM’s global.
Test is executed in VM’s global.

A reduced repro of this behavior looks like this:

const vm = require('vm');
const jsdom = require('jsdom');

const env = new jsdom.JSDOM('<!DOCTYPE html>', {
  runScripts: 'dangerously',
});

vm.createContext(env.window);

const testcode = `
  ((console) => {
    try {
      non_existent_variable_that_throws_not_defined_error;
    } catch (e) {
      console.log(e);
      console.log('caught error instanceof Error: ', e instanceof Error);;
    }
  })
`;
vm.runInContext(testcode, env.window)(console);

Reproduction without JSDOM

const vm = require('vm');

const context = { Error, console };
vm.createContext(context);

const testcode = `
  try {
    non_existent_variable_that_throws_not_defined_error;
  } catch (e) {
    console.log(e);
    console.log('caught error instanceof Error: ', e instanceof Error);;
  }
`;
vm.runInContext(testcode, context);

This code prints “false” because:

the error in the global scope is coming from a parent execution context
the error that we catch is generated by native c++ code and thus created by the child execution context
these two errors are technically different in terms of instanceof’ing.

Now, rimraf is doing an instanceof check for some of the errors it’s getting from FS module:

https://github.com/isaacs/rimraf/blob/d709272f6122b008de66650616fda34c8ae6f954/rimraf.js#L168

This check fails and yields this error.

Mitigation

Unfortunately, configuring jest to run in a testEnvironment: node (and thus not bringing in JSDOM) doesn’t help to mitigate this issue, because jest’s NodeEnvironment is doing a very similar thing. (And there seem to be some workarounds for some similar problems)

Short-term, we should try fixing this upstream in rimraf - instead of instanceof’ing errors, it’d be probably fine to check for existence of a stack property.

Long-term, I wonder if there’s something Jest can do better on their side to avoid this cross-vm type passing.