Skip to main content
interlace
Plugin: import-nextRules

prefer-direct-import

Prefer direct imports over barrel imports for better tree-shaking and build performance

💼 This rule is enabled in the following configs: recommended, typescript. 🔧 This rule is automatically fixable by the --fix CLI option. 💡 This rule is manually fixable by editor suggestions.

Rule Details

Reports a named import from a barrel that mappings describes, and rewrites it to the direct module. Each mapping names a barrel specifier (barrel, a regular expression) and the direct path of one export (directPath, where {name} is the imported name).

Reported: import { Button } from '@/ui', a renamed specifier, several specifiers (one report each; fixed only when there is one), the value specifiers of an import that mixes in inline type ones, and export { Button } from '@/ui'. With autoFix: true (the default) a single specifier is fixed; with false the rewrite is offered as a suggestion.

Not reported: a specifier no mapping names, a path already direct, default, namespace and side-effect imports and export * (no export name to map), type-only imports (import type, all-inline type: erased), require() and import().

Without mappings, the rule applies built-in mappings for @/components, @/hooks, @/utils, @/lib, ~/components and ~/hooks to <barrel>/<name>. Configure mappings to match your layout: the rewrite does not check that the direct module exists.

// { mappings: [{ barrel: '^@/ui$', directPath: '@/ui/{name}' }] }

// ❌ Incorrect
import { Button } from '@/ui';

// ✅ Correct
import { Button } from '@/ui/Button';
import type { Props } from '@/ui';

Options

[
  {
    "type": "object",
    "properties": {
      "mappings": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "barrel": {
              "type": "string"
            },
            "directPath": {
              "type": "string"
            }
          },
          "required": [
            "barrel",
            "directPath"
          ]
        },
        "default": [],
        "description": "Mapping of barrel paths to direct import patterns"
      },
      "autoFix": {
        "type": "boolean",
        "default": true,
        "description": "Auto-fix the imports when possible"
      }
    },
    "additionalProperties": false
  }
]

Implementation

OWASP Foundation

  • Category: A00:2021 - General Security

Use this rule

npm install -D oxlint-plugin-import-next
.oxlintrc.json
{  "jsPlugins": ["oxlint-plugin-import-next"],  "rules": {    "import-next/prefer-direct-import": "error"  }}
vite.config.ts
import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-import-next'],    rules: {      'import-next/prefer-direct-import': '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.