Skip to main content
interlace
Plugin: import-nextRules

no-named-export

Prevents named exports

💼 This rule is enabled in the following configs: recommended, typescript.

Rule Details

A convention: every module publishes one default export and nothing else. This rule reports every value named export:

  • export const / let / var (also destructured, one per bound name), export function, export class, export enum;
  • an export list, also renamed or under a string name (export { b as "a" });
  • export { a } from 'm', export * from 'm' (it publishes every name of m) and export * as ns from 'm'.

Not reported: anything exported as default (export { x as default }, export * as default from 'm'); type-only exports (export type, export interface, export type { T }, export { type T }, export const enum); a bare export {}.

❌ Incorrect

export const a = 1;
export enum Color {
  Red,
}
export * from './utils';

✅ Correct

export default function load() {}
export type Options = { retries: number };
const a = 1;
export { a as default };

Options

[
  {
    "type": "object",
    "properties": {
      "allowInFiles": {
        "type": "array",
        "items": {
          "type": "string"
        },
        "description": "File globs (or path substrings) where named exports are allowed."
      },
      "allowNames": {
        "type": "array",
        "items": {
          "type": "string"
        },
        "description": "Exported names that are allowed."
      },
      "allowPatterns": {
        "type": "array",
        "items": {
          "type": "string"
        },
        "description": "More file globs (or path substrings) where named exports are allowed."
      },
      "suggestDefault": {
        "type": "boolean",
        "default": true,
        "description": "Has no effect; accepted so existing configs keep validating."
      }
    },
    "additionalProperties": false
  }
]
  • allowNames (default []): exported names that are accepted. export * from 'm' publishes names the file cannot see and is never covered by this list.
  • allowInFiles (default []): file globs (or path substrings) where named exports are accepted.
  • allowPatterns (default []): more file globs (or path substrings), same meaning as allowInFiles.
  • suggestDefault: has no effect; accepted so existing configs keep validating.

A glob matches any run of whole path segments, so src/*.test.ts matches an absolute filename.

When Not To Use It

In most codebases: named exports are the common convention. Use it only where a framework requires a single default export per file.

Use this rule

npm install -D oxlint-plugin-import-next
.oxlintrc.json
{  "jsPlugins": ["oxlint-plugin-import-next"],  "rules": {    "import-next/no-named-export": "error"  }}
vite.config.ts
import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-import-next'],    rules: {      'import-next/no-named-export': 'error',    },  },});

oxlint-plugin-import-next re-exports eslint-plugin-import-next/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.

Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.