no-require-imports
Disallow invocation of
require()
.
Extending "plugin:@typescript-eslint/recommended"
in an ESLint configuration enables this rule.
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()
.
- Flat Config
- Legacy Config
export default tseslint.config({
rules: {
"@typescript-eslint/no-require-imports": "error"
}
});
module.exports = {
"rules": {
"@typescript-eslint/no-require-imports": "error"
}
};
Try this rule in the playground ↗
Examples
- ❌ Incorrect
- ✅ Correct
const lib1 = require('lib1');
const { lib2 } = require('lib2');
import lib3 = require('lib3');
Open in Playgroundimport * as lib1 from 'lib1';
import { lib2 } from 'lib2';
import * as lib3 from 'lib3';
Open in PlaygroundOptions
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$'] }
:
- ❌ Incorrect
- ✅ Correct
console.log(require('../data.json').version);
Open in Playgroundconsole.log(require('../package.json').version);
Open in PlaygroundallowAsImport
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 }
:
- ❌ Incorrect
- ✅ Correct
var foo = require('foo');
const foo = require('foo');
let foo = require('foo');
Open in Playgroundimport foo = require('foo');
import foo from 'foo';
Open in PlaygroundUsage 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 require
s, 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 require
s then you might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.