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{ "jsPlugins": ["oxlint-plugin-import-next"], "rules": { "import-next/prefer-direct-import": "error" }}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.