Skip to main content

no-require-imports

Disallow invocation of require().

Depending on your TSConfig settings and whether you're authoring ES Modules or CommonJS, TS may allow both import and require() to be used, even within a single file.

This rule enforces that you use the newer ES Module import syntax over CommonJS require().

eslint.config.mjs
export default tseslint.config({
rules: {
"@typescript-eslint/no-require-imports": "error"
}
});

Try this rule in the playground ↗

Examples

const lib1 = require('lib1');
const { lib2 } = require('lib2');
import lib3 = require('lib3');
Open in Playground

Options

This rule accepts the following options:

type Options = [
{
/** Patterns of import paths to allow requiring from. */
allow?: string[];
/** Allows `require` statements in import declarations. */
allowAsImport?: boolean;
},
];

const defaultOptions: Options = [{ allow: [], allowAsImport: false }];

allow

Patterns of import paths to allow requiring from. Default: [].

These strings will be compiled into regular expressions with the u flag and be used to test against the imported path. A common use case is to allow importing package.json. This is because package.json commonly lives outside of the TS root directory, so statically importing it would lead to root directory conflicts, especially with resolveJsonModule enabled. You can also use it to allow importing any JSON if your environment doesn't support JSON modules, or use it for other cases where import statements cannot work.

With { allow: ['/package\\.json$'] }:

console.log(require('../data.json').version);
Open in Playground

allowAsImport

Allows require statements in import declarations. Default: false.

When set to true, import ... = require(...) declarations won't be reported. This is beneficial if you use certain module options that require strict CommonJS interop semantics, such as verbatimModuleSyntax.

With { allowAsImport: true }:

var foo = require('foo');
const foo = require('foo');
let foo = require('foo');
Open in Playground

Usage with CommonJS

While this rule is primarily intended to promote ES Module syntax, it still makes sense to enable this rule when authoring CommonJS modules.

If you prefer to use TypeScript's built-in import ... from ... ES Module syntax, which is transformed to require() calls during transpilation when outputting CommonJS, you can use the rule's default behavior.

If, instead, you prefer to use require() syntax, we recommend you use this rule with allowAsImport enabled. That way, you still enforce usage of import ... = require(...) rather than bare require() calls, which are not statically analyzed by TypeScript. We don't directly a way to prohibit ES Module syntax from being used; consider instead using TypeScript's verbatimModuleSyntax option if you find yourself in a situation where you would want this.

When Not To Use It

If you are authoring CommonJS modules and your project frequently uses dynamic requires, then this rule might not be applicable to you. Otherwise the allowAsImport option probably suits your needs.

If only a subset of your project uses dynamic requires then you might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.

Resources