no-dynamic-require

📡 Live from GitHub — This documentation is fetched directly from no-dynamic-require.md and cached for 6 hours.

Keywords: dynamic require, CommonJS, static analysis, bundler, ESLint rule, webpack, LLM-optimized

Forbid require() calls with non-literal arguments

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

Quick Summary

Aspect	Details
Severity	Warning (architecture)
Auto-Fix	❌ No (requires architecture change)
Category	Security
ESLint MCP	✅ Optimized for ESLint MCP integration
Best For	Bundler optimization, static analysis

Rule Details

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

Why This Matters

Issue	Impact	Solution
📦 Bundle size	Can't tree-shake	Static imports
🔍 Static analysis	Tools can't analyze deps	Literal paths
🔒 Security	Arbitrary module loading	Explicit imports

Examples

❌ Incorrect

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

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

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

✅ Correct

// 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 Examples

Basic Usage

{
  rules: {
    'architecture/no-dynamic-require': 'warn'
  }
}

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

Known False Negatives

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

Dynamic Variable References

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 Functions

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 Flow

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.