
Security News
Crates.io Users Targeted by Phishing Emails
The Rust Security Response WG is warning of phishing emails from rustfoundation.dev targeting crates.io users.
@morev/eslint-disable-autofix
Advanced tools
This utility allows you to disable autofix for specific ESLint rules by using a custom prefix in your configurations.
It's useful when you want a rule to remain active for linting purposes but prevent ESLint from automatically fixing it.
[!NOTE] This is a temporary solution until this RFC is accepted and a final implementation is made that closes this issue - after that the feature for disabling autofix for rules will be in the ESLint core.
I am working on RFC development and final implementation in the core myself, but the process will take some time, and the problem is already there.
I'll probably be able to implement this as a polyfill for the final solution, once the RFC discussion reaches a consensus on a public API.
[!IMPORTANT]
- Only works with ESLint v9 and its flat config format;
- You have to restart ESLint server after adding/removing
no-autofix/
prefix to take effect.
Some rules support autofixing, which is often convenient, but in certain cases
the fixes may be broken, unsafe, or simply undesirable.
Ideally, unsafe autofixes should be treated as suggestions, and broken fixes should be reported.
However, ESLint is a large ecosystem, and some useful plugins are no longer actively maintained.
Even in actively maintained projects, users may want to disable autofixing for specific rules
due to project-specific or personal preferences.
pnpm add -D @morev/eslint-disable-autofix
yarn add @morev/eslint-disable-autofix -D
npm install -D @morev/eslint-disable-autofix
In your eslint.config.js
(only flat config is supported):
import { disableAutofix } from '@morev/eslint-disable-autofix';
import somePlugin from 'some-eslint-plugin';
export default disableAutofix([
{
plugins: {
'some-plugin': somePlugin,
},
rules: {
// Disable autofix for a core rule
'no-autofix/no-var': 'error',
// Disable autofix for a third-party rule
'no-autofix/some-plugin/some-rule': 'warn',
},
},
]);
If you'd prefer a custom prefix other than no-autofix/
, use the factory:
import { createDisableAutofix } from '@morev/eslint-disable-autofix';
const disableAutofix = createDisableAutofix({
prefix: 'disable-autofix',
});
export default disableAutofix([
{
rules: {
'disable-autofix/no-var': 'error',
},
},
]);
Under the hood, it uses eslint-rule-composer
to wrap rules with autofix disabled.
[!CAUTION] Direct patching is quite risky and hacky, it relies on non-public ESLint API.
While it's currently the only way to access certain rule internals, it may break in future ESLint versions.
I've been using eslint-plugin-no-autofix for a long time and haven't had much trouble with it, however recently problems have arisen:
Some popular plugins (like eslint-plugin-unicorn or eslint-stylistic) switch to the ESM-only distribution format and eslint-plugin-no-autofix doesn't work with it. The issue have no response, so I've decided to create my own solution that works in a different way.
I'm getting tired of rules being renamed just to make them work.
Say I need to disable a rule with autofix turned off for a single file - I write /* eslint-disable no-autofix/unicorn/no-lonely-if */
.
Later, the broken autofix in the original rule gets fixed, I re-enable the main rule,
and now the directive no longer applies, which leads to unexpected changes I didn't want.
Patching the original rules instead of creating new ones might be a bit riskier technically, but from a developer experience perspective, it's definitely cleaner and more intuitive.
FAQs
Utility to disable autofix for specific ESLint rules
We found that @morev/eslint-disable-autofix demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
The Rust Security Response WG is warning of phishing emails from rustfoundation.dev targeting crates.io users.
Product
Socket now lets you customize pull request alert headers, helping security teams share clear guidance right in PRs to speed reviews and reduce back-and-forth.
Product
Socket's Rust support is moving to Beta: all users can scan Cargo projects and generate SBOMs, including Cargo.toml-only crates, with Rust-aware supply chain checks.