
Research
Malicious fezbox npm Package Steals Browser Passwords from Cookies via Innovative QR Code Steganographic Technique
A malicious package uses a QR code as steganography in an innovative technique.
@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.
Research
A malicious package uses a QR code as steganography in an innovative technique.
Research
/Security News
Socket identified 80 fake candidates targeting engineering roles, including suspected North Korean operators, exposing the new reality of hiring as a security function.
Application Security
/Research
/Security News
Socket detected multiple compromised CrowdStrike npm packages, continuing the "Shai-Hulud" supply chain attack that has now impacted nearly 500 packages.