no-dynamic-require

Forbid require() calls with non-literal arguments. This rule is part of eslint-plugin-node-security.

Quick SummaryCopy Anchor Link

Rule DetailsCopy Anchor Link

Dynamic require() calls prevent static analysis and break tree-shaking in bundlers.

Why This MattersCopy Anchor Link

ExamplesCopy Anchor Link

❌ IncorrectCopy Anchor Link

const moduleName = getModuleName();
const mod = require(moduleName);  // Dynamic

const plugin = require(`./plugins/${name}`);  // Template literal

const handler = require(path.join(__dirname, name));  // Computed

✅ CorrectCopy Anchor Link

// Static requires
const mod = require('./module');

// Dynamic import (when truly needed)
const mod = await import(`./plugins/${name}`);

// Explicit mapping
const plugins = {
  a: require('./plugins/a'),
  b: require('./plugins/b'),
};
const plugin = plugins[name];

Configuration ExamplesCopy Anchor Link

Basic UsageCopy Anchor Link

{
  rules: {
    'node-security/no-dynamic-require': 'warn'
  }
}

Related RulesCopy Anchor Link

• no-commonjs - Prevent CommonJS usage
• no-unsafe-dynamic-require - Security-focused variant

Further ReadingCopy Anchor Link

• Webpack Dynamic Imports - Code splitting guide

Known False NegativesCopy Anchor Link

The following patterns are not detected due to static analysis limitations:

Dynamic Variable ReferencesCopy Anchor Link

Why: Static analysis cannot trace values stored in variables or passed through function parameters.

// ❌ NOT DETECTED - Value from variable
const value = externalSource();
processValue(value); // Variable origin not tracked

Mitigation: Implement runtime validation and review code manually. Consider using TypeScript branded types for validated inputs.

Wrapped or Aliased FunctionsCopy Anchor Link

Why: Custom wrapper functions or aliased methods are not recognized by the rule.

// ❌ NOT DETECTED - Custom wrapper
function myWrapper(data) {
  return internalApi(data); // Wrapper not analyzed
}
myWrapper(unsafeInput);

Mitigation: Apply this rule's principles to wrapper function implementations. Avoid aliasing security-sensitive functions.

Cross-Module Data FlowCopy Anchor Link

Why: ESLint rules analyze one file at a time. Values imported from other modules cannot be traced.

// ❌ NOT DETECTED - Value from import
import { getValue } from './helpers';
processValue(getValue()); // Cross-file not tracked

Mitigation: Apply the same rule to imported modules. Use module boundaries and explicit exports.

⚙️ OptionsCopy Anchor Link

Not a findingCopy Anchor Link

The question is whether a specifier can change, not whether it is spelled as a literal. Resolution runs through ESLint's scope analysis, so all of these are silent:

If it fires, the specifier reaches a name this file cannot resolve — a parameter, an import, a variable written more than once. That is genuinely unknowable here, which is exactly the case the rule exists for.

Use this rule

npm install -D oxlint-plugin-node-security

{  "jsPlugins": ["oxlint-plugin-node-security"],  "rules": {    "node-security/no-dynamic-require": "error"  }}

import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-node-security'],    rules: {      'node-security/no-dynamic-require': 'error',    },  },});