oxc-project/oxc · warning

Do not export from a test file.

Error message

Do not export from a test file.

What it means

This is oxlint's 'jest/no-export' diagnostic. It fires when a file that contains Jest tests (any recognized describe/test/it call from the jest plugin) also contains an ES export statement. Exporting from a test file invites other tests to import it, coupling suites together and causing double-execution or shared mutable state; the help suggests moving shared code into its own module.

Source

Thrown at crates/oxc_linter/src/rules/jest/no_export.rs:14

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;

use crate::context::LintContext;
use crate::rule::Rule;
use crate::utils::{
    JestFnKind, JestGeneralFnKind, is_jest_file, iter_possible_jest_call_node,
    parse_general_jest_fn_call,
};

fn no_export_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Do not export from a test file.")
        .with_help("If you want to share code between tests, move it into a separate file and import it from there.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoExport;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Prevents using exports if a file has one or more tests in it.
    ///
    /// ### Why is this bad?
    ///
    /// This rule aims to eliminate duplicate runs of tests by exporting things from test files.
    ///  If you import from a test file, then all the tests in that file will be run in each imported instance.
    /// so bottom line, don't export from a test, but instead move helper functions into a separate file when they need to be shared across tests.
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Move the exported helpers/fixtures into a separate non-test module (e.g. test-utils.ts) and import them from the test files.
  2. If the export is dead, delete it.
  3. If the file is not really a test file, rename it so it no longer matches test file patterns.
  4. For deliberate exceptions, disable the rule for that path via .oxlintrc.json overrides or an inline oxlint-disable comment.

Example fix

// before (utils.test.ts)
export function makeUser() { return { id: 1 }; }
it('creates user', () => { expect(makeUser().id).toBe(1); });

// after (test-utils.ts)
export function makeUser() { return { id: 1 }; }

// (utils.test.ts)
import { makeUser } from './test-utils';
it('creates user', () => { expect(makeUser().id).toBe(1); });
Defensive patterns

Strategy: validation

Validate before calling

// find exports inside test files
const { execSync } = require('node:child_process');
console.log(execSync("rg -n '^\\s*export\\s+(const|function|class|default|\\{)' --glob '*.test.*' --glob '*.spec.*' tests/ src/", { encoding: 'utf8' }));

Prevention

When it happens

Trigger: Enable the jest/no-export rule and lint a file where is_jest_file / iter_possible_jest_call_node finds a test or hook call AND the module record contains an export entry (export const ..., export function ...). Each export span gets the diagnostic.

Common situations: Test files that export helpers, fixtures, or mock factories 'for reuse by sibling tests' are the classic trigger — common in repos without a dedicated test-utils module. Also hit when a production module is accidentally renamed to a *.test.* file or a spec file gains an export during refactoring.

Related errors


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/9261edacb1c939be. Report an issue: GitHub.