eslint-plugin-regexp turns regex mistakes into lint errors

Eighty rules covering mistakes, style and optimisation hints

eslint-plugin-regexp is an ESLint plugin for finding RegExp mistakes and RegExp style guide violations, and the README lists three things it provides. It finds the wrong usage of regular expressions together with hints, it enforces a consistent style of regular expressions, and it finds hints for writing optimised regular expressions. The rule count is eighty, covering regular expression syntax and features. That is a wide surface, and the rules fall into categories, the first of which in the generated list is Possible Errors. The examples there show what the category means. There is a rule that disallows elements that contradict assertions, one that disallows duplicate disjunctions, one that disallows alternatives without elements, one that disallows a capturing group that captures empty, one that disallows character classes that match no characters, one that disallows empty groups, and one that disallows an empty lookahead assertion or empty lookbehind. Every one of those is a class of bug that passes review easily and fails at runtime on data nobody tested with.

The recommended preset is a subset, and that is the point

The plugin ships two configurations and the distinction between them matters more than the rule count. The plugin.configs.recommended config enables a subset of the rules that should be most useful to most users, and the plugin.configs.all config enables all rules. The documentation is explicit that all is meant for testing and not for production use because it changes with every minor and major version of the plugin, and it says to use it at your own risk. That is the correct advice, and the reason is worth understanding. A rule set that changes shape between minor releases will produce new warnings in your CI without any change to your code. A team that adopts all will spend its first weeks reading reports about rules it never opted into and will eventually disable the config to make the pipeline green. The recommended set is the one that changes least between versions and the one a team can adopt without a negotiation.

Wiring it into a flat config file

Installation is a single dev dependency install alongside ESLint itself:

npm install --save-dev eslint eslint-plugin-regexp

The stated requirements are ESLint v9.38.0 and above, and Node.js v20.19.0, v22.13.0, v24 and above. The package.json encodes the same Node range as ^20.19.0 || ^22.13.0 || >=24, and the package is an ES module with type set to module, so it is published for the flat config era rather than the old .eslintrc format. To use it you add regexp to the plugins section of your eslint.config.js file, with the eslint-plugin- prefix optional, and then either pick one of the two configurations or list the rules you want. The recommended configuration is a one-liner:

// eslint.config.js
import regexpPlugin from "eslint-plugin-regexp"

export default [
    regexpPlugin.configs.recommended,
];

If you want to override or add specific rules, the plugin is registered under the plugins key and rules are set by their namespaced names:

// eslint.config.js
import regexpPlugin from "eslint-plugin-regexp"

export default [
    {
        plugins: { regexp: regexpPlugin },
        rules: {
            // Override/add rules settings here, such as:
            "regexp/rule-name": "error"
        }
    }
];

The rule identifiers are prefixed with regexp/, and the placeholder in that snippet shows the shape of an override.

Some rules can be fixed automatically, others need a human

The generated rules table carries a set of markers that tell you what kind of intervention each rule allows. A wrench marker marks a rule that is automatically fixable by the --fix command line option, and a bulb marker marks a rule that is manually fixable by editor suggestions. Looking at the Possible Errors entries, most of them carry the suggestion marker and no fix marker, which reflects the nature of the problems. An empty character class or a contradiction with an assertion has no mechanical repair, since the fix depends on what the author meant to match. A style rule, on the other hand, is usually mechanical, because consistency means one canonical spelling of the same construct. That distinction has a practical consequence for how you roll this out. Style findings can be auto-fixed in a first pass and reviewed as a formatting diff, which is a much easier review than a list of semantic findings, and semantic findings should be raised as issues one at a time rather than as a wall of warnings.

A repository built for adding rules, with a docs pipeline

The layout of the repository shows a project that expects to grow. There is a lib/ directory for the implementation, tests/ for the test suite, docs/ for the documentation, tools/ for scripts, typings/ for type declarations, and a .changeset/ directory, which is the mechanism used to record pending version bumps. The package.json scripts reveal the whole workflow. The build uses tsdown, with a clean step that removes the nyc output, dist and coverage directories, and the test script runs the build first via pretest, then the mocha suite with a sixty second timeout, wrapped in c8 for coverage. A separate typecheck script runs tsc against tsconfig.build.json with noEmit. The docs are served with vitepress through a docs:watch script. Most telling are the update scripts, one that runs tools/update.ts followed by an eslint fix pass and the eslint-doc-generator, and another for the Unicode alias table. There is also a new script pointing at tools/new-rule.ts, which means adding a rule is a scripted path rather than a manual edit, and the eslint-doc-generator is what keeps the rule table in the README in step with the code.

Where the plugin stops short of measuring performance

The limitation to keep in mind is the one implied by the third bullet in the feature list. The plugin finds hints for writing optimised regular expressions, and a hint is not a measurement. There is no benchmark in this project, no profiling and no per-pattern timing, so a rule can tell you that a construct is likely to be slow and it cannot tell you by how much, or that your change made it faster. The rules are about the shape of the pattern, such as avoiding constructs that backtrack badly, not about runtime cost on your data. That is a reasonable design, because a lint rule cannot know your input distribution, but it does mean the plugin complements performance testing rather than replacing it. The other limit is the coverage of the languages and syntax you use. The rule set is about regular expression syntax and features, so a rule that exists for one dialect may not apply to the engine you actually run, and the documentation for each rule is where that detail lives. The plugin also cannot find the regex you wrote in a dynamically constructed string, because it works on the literal patterns it can parse statically.

Maintenance state, versions and licence

The repository is not archived and the last push was on 2026-10-13. Releases are frequent and follow a clear semver shape, with v3.3.1 published on 2026-09-20, v3.3.0 on 2026-09-04 and v3.2.0 on 2026-08-13, and the version field in package.json reads 3.3.1. Because the plugin follows semver and the README warns that the all configuration changes with every minor and major version, a team on the recommended preset can take minor upgrades with far less friction than one on all. The licence is MIT, with a LICENSE file at the root, which is the permissive case for a lint plugin that a team may well want to fork to add a rule for their own codebase. The CHANGELOG.md at the root and the .changeset directory are where to look before an upgrade. The published package ships only the dist directory, and the exports map exposes the package root and its package.json, with types resolved from dist/index.d.ts.

Editorial conclusion

Adopt eslint-plugin-regexp when your codebase has enough regular expressions that hand review misses the obvious ones, and when a lint rule is an easier sell in code review than a comment about backtracking. Do not adopt it as a performance analyser, since the optimisation rules offer hints rather than measurements, and do not enable the all configuration in production, as the documentation says it is meant for testing and changes with every minor and major version. Verify first that your ESLint version is at least v9.38.0 and your Node.js version satisfies the stated range, then enable the recommended preset and read the warnings it produces before switching individual rules to error.

Frequently asked questions

Official sources

1. License: MIT
2. ota-meshi/eslint-plugin-regexp on GitHub
3. Project website
4. README
5. Releases