no-internal-modules
Forbid importing the submodules of other modules
š¼ 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
Code should import a module through its entry point, not reach into its files. Every way a module is loaded or re-exported is checked: import, side-effect import, export ā¦ from, export * from, require(), import() and TypeScript's import x = require().
A specifier's depth is how many path segments it goes past the module root: a package (lodash 0, lodash/get 1, lodash/fp/get 2), a scoped package (@org/ui 0, @org/ui/button 1), a relative path (each segment after the ./ / ../ prefix: ./utils 1, ./utils/helpers 2, ../../a/b 2). A trailing slash names the same module (./utils/ is ./utils). A specifier deeper than maxDepth (default 1), or matching a forbid glob, is reported - unless it matches an allow or ignorePaths glob (* within a segment, ** across segments). strategy (error, warn, autofix, suggest) only decides how a finding is fixed.
ā Incorrect
import helpers from './utils/helpers';
import get from 'lodash/fp/get';
export * from '@org/ui/button/icon';ā Correct
import utils from './utils';
import get from 'lodash/get';
// { allow: ['lodash/**'] }
import fpGet from 'lodash/fp/get';Options
[
{
"type": "object",
"properties": {
"maxDepth": {
"type": "number",
"minimum": 0,
"default": 1,
"description": "Maximum allowed depth of module imports (0 = only root, 1 = one level deep)"
},
"allow": {
"type": "array",
"items": {
"type": "string"
},
"default": [],
"description": "Glob patterns for paths that are allowed regardless of depth"
},
"forbid": {
"type": "array",
"items": {
"type": "string"
},
"default": [],
"description": "Glob patterns for paths that are explicitly forbidden"
},
"ignorePaths": {
"type": "array",
"items": {
"type": "string"
},
"default": [],
"description": "Glob patterns for paths to ignore completely"
},
"strategy": {
"type": "string",
"enum": [
"error",
"warn",
"autofix",
"suggest"
],
"default": "error",
"description": "How to handle violations: error (report), warn (report), autofix (fix automatically), suggest (provide suggestions)"
}
},
"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/no-internal-modules": "error" }}import { defineConfig } from 'vite-plus';export default defineConfig({ lint: { jsPlugins: ['oxlint-plugin-import-next'], rules: { 'import-next/no-internal-modules': '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.