Cypress Support Files

What Support Files Do

The support file, cypress/support/e2e.js by default, runs before every single spec file, making it the natural place for imports, global custom commands, and suite-wide hooks like a global beforeEach().

By convention, custom commands typically live in a separate cypress/support/commands.js file, imported from e2e.js, keeping command definitions separate from other global setup concerns.

// cypress/support/e2e.js
import './commands';

beforeEach(() => {
  cy.intercept('GET', '/api/feature-flags', { fixture: 'feature-flags.json' });
});

This global beforeEach() runs before every test in every spec file, stubbing feature flags consistently everywhere.

Default Support File Layout

cypress/support/
  e2e.js         // loaded before every E2E spec
  commands.js    // custom command definitions, imported by e2e.js
  component.js   // loaded before every component test spec (if used)

• e2e.js is configurable via the supportFile setting, but rarely needs to change.
• Splitting commands into their own file keeps e2e.js focused on global setup and imports.
• Component testing uses its own separate support file, since its needs differ from E2E.
• Disabling the support file entirely is possible by setting supportFile: false, though uncommon.

Support Files Cheat Sheet

Common contents worth placing in support files as a project matures.

Handling Uncaught Exceptions Globally

By default, an uncaught JavaScript exception anywhere in the application under test fails the current Cypress test. Sometimes a known, harmless third-party error needs to be ignored globally, which the support file's uncaught:exception handler makes possible.

// cypress/support/e2e.js
Cypress.on('uncaught:exception', (err) => {
  if (err.message.includes('ResizeObserver loop limit exceeded')) {
    return false; // prevent this specific, known-harmless error from failing the test
  }
  // otherwise, let Cypress fail the test as normal
});

Be as specific as possible in the condition, silencing exceptions too broadly can hide real bugs.

Organizing a Growing Support Folder

As a project's command library grows, splitting commands.js into feature-specific files (auth, forms, api) and importing them all from a single index keeps things navigable, mirroring how you might organize application source code itself.

// cypress/support/commands/index.js
import './auth';
import './forms';
import './api';

// cypress/support/e2e.js
import './commands';

Common Mistakes

• Silencing uncaught exceptions too broadly, hiding genuine application bugs from the test suite.
• Letting commands.js grow into an unorganized, thousand-line file with no internal structure.
• Forgetting that support files run before every spec, and unintentionally adding slow setup logic there.
• Not realizing component testing has its own separate support file with different relevant setup.

Key Takeaways

• Support files run before every spec file and are the natural home for global setup and custom commands.
• e2e.js and commands.js are conventionally separated for clarity as a project grows.
• Global uncaught exception handling should target specific, known errors, not swallow all errors broadly.
• Splitting a growing command library into feature-specific files keeps it maintainable.