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
- Move the exported helpers/fixtures into a separate non-test module (e.g. test-utils.ts) and import them from the test files.
- If the export is dead, delete it.
- If the file is not really a test file, rename it so it no longer matches test file patterns.
- 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
- Keep a dedicated test-utils/helpers module for anything shared between spec files.
- Never import from a *.test.* file; add a review rule against it.
- Watch for accidental exports when renaming production files into test globs.
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
- Require a message for {matcher_name:?}.
- `jest.setTimeout` should only be called in a global scope
- Do not call `jest.setTimeout` multiple times
- `jest.setTimeout` should be placed before any other jest met
- {deprecated:?} has been deprecated in favor of {new:?}
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/9261edacb1c939be.
Report an issue: GitHub.