Random test crashes with "window is not defined" error

Describe the bug

From time to time I get the error ReferenceError: window is not defined.

or

Reproduction

I couldn’t find any pattern. It just happens sometimes.

This happens with any value of environment, and happy-dom and jsdom.

vitest.config.ts:

/// <reference types="vitest" />

import path from 'path';
import { defineConfig } from 'vite';

// eslint-disable-next-line import/no-default-export -- by design
export default defineConfig({
  test: {
    environment: 'happy-dom',
    include: ['**/*.test.ts'],
    setupFiles: [path.resolve(__dirname, 'vitest.setup.ts')],
  },
});

System Info

System:
    OS: macOS 12.2.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 2.14 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.15.0 - /usr/local/bin/node
    Yarn: 1.22.18 - /usr/local/bin/yarn
    npm: 8.5.5 - /usr/local/bin/npm
  Browsers:
    Brave Browser: 101.1.38.111
    Chrome: 101.0.4951.54
    Chrome Canary: 103.0.5057.0
    Firefox: 100.0
    Safari: 15.3
  npmPackages:
    vite: ^2.9.9 => 2.9.9 
    vitest: ^0.12.4 => 0.12.4

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[odinho]

It seems like vitest should not tear down the environment if there’s still stuff in the event queue then?

I get that this is some async thing that’s coming in late, but usually it would find window and it’d be a-ok. Never had this issue with jest which we just came from (same tests), which might indicate that they do wait(?).

If it is meant to be a feature, then it should always warn about things being run after teardown, and not just when it crashes due to an env issue.

These are some quite big integration tests, and I’m also unable to tell which tests they came from, even almost-so. The console.log I put in doesn’t happen for this after-teardown run, only for things inside the test. 🤔

[dartess]

@vincent-lecrubier-skydio unfortunately I can’t give you the right solution. I just refactored the code.