The indent rule seems impossible to disable; how (in config settings) do I disable this rule? thanks.
Set the rule to "off" in your config like this:
"rules": {
"indent": "off"
}
You can read more in the docs here.
For indentation, I usually let it activated in config and disable it only in some files where I need a fancy indentation, hence I use the comment
/* eslint-disable indent */
It is worth to note that this works also with standardJS as well as on any other linter powered by eslint.
I had to add more rules. To turn off linting for react and jsx-indent
"rules": {
"indent": "off",
"react/jsx-indent": "off",
"react/jsx-indent-props": "off"
}
This is the one that worked for me
"indent": ["error", ""],
Related
I have a Next.js project that is configured to use Prettier & ESLint. I want to enable the Prettier rule "trailingComma" by setting its value to "all", such that the .prettierrc file contains the following:
// ".prettierrc"
{
"trailingComma": "all"
}
I am using an .eslintrc.json file to configure ESLint, and I have it configured to apply a couple of plug-ins, and to extend a couple of the plug-in's rule-sets.
This is an image of my file:
{
"next",
"next/core-web-vitals",
"prettier",
"eslint:recommended",
"plugin:jsx-a11y/recommended",
"plugin:prettier/recommended",
"plugin:typescript-eslint/recommended",
}
The following ESLint rule is the rule ESLint uses to configure commas:
"comma-dangle": "off",
This rule is shown to affect the trailingComma rule, as it is mentioned in the error message:
"prettier/prettier": ["error", {}, { "usePrettierrc": true }],
Prettier seems to execute when I save, and the commas are added to the end of the list, but then I get the following error message (shown in the image).
I tried adding the "endOfLine" option both to .prettierrc and .eslintrc.json rule "prettier/prettier", someone said that it would fix the issue, but it didn't fix it.
How can I keep the trailing commas from displaying errors in the editor?
I'm always reading that Prettier is the go to for formatting and ESlint for highlighting linting errors despite ESlint also being able to format.
However Prettier does not have advanced formatting options like padding-line-between-statements which is available in ESlint
With the settings.json (vscode settings) see bottom of page, it will use eslint to format then what purpose is setting the editor.defaultFormatter to Prettier?
I can also see that Prettier rules (.prettierc) are also used when ESlint does the formatting in these settings.
Does the ESlint extends: prettier option in .eslintrc use the settings in .prettierrc and that is why using ESlint to format reads .prettierrc rules too?
Whereas updating vscode settings to the following to use Prettier to formatOnSave...
// prettier as formatter
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
...does not apply eslint rules when formatting
A suggestion was to added eslint-plugin-prettier..
When I set "editor.defaultFormatter": "dbaeumer.vscode-eslint" and add ["prettier"] to plugins and {"prettier/prettier": "error"} to rules, Prettier does nothing. It is only when "editor.defaultFormatter" is set to Prettier, does Prettier then work but ignores ESLint.
So question is why use prettier when it isn't doing the formatting in "source.fixAll.eslint" setting and when it is doing the formatting, it is no where near the advanced formatting ESLint provides?
//eslintrc
{
"env": {
"browser": true,
"es2021": true
},
"extends": ["eslint:recommended", "plugin:#typescript-eslint/recommended","prettier"],
"parser": "#typescript-eslint/parser",
"parserOptions": {
"ecmaVersion": 12,
"sourceType": "module"
},
"plugins": ["#typescript-eslint"],
"rules": {
"semi": ["error", "never"]
}
}
//.prettierrc
{
"semi": false,
"arrowParens": "avoid",
"printWidth": 120,
"tabWidth": 2
}
//settings.json (vscode settings)
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": [
"source.organizeImports",
"source.fixAll.eslint"
},
Does the ESlint extends: prettier option use the settings in .prettierrc and that is why using ESlint to format reads .prettierrc rules too?
No. It disables all the Eslint rules that would clash with Prettier.
If you want eslint to also check and run prettier with your configuration, set up eslint-plugin-prettier.
Is there a way to disable use of eslint disable overrides?
For example, block the use of /* eslint disable-next-line */, etc so that a specific rule is enforced always without exception
https://eslint.org/docs/user-guide/configuring/rules#disabling-inline-comments
To disable all inline config comments, use the noInlineConfig setting. For example:
{
"rules": {...},
"noInlineConfig": true
}
Unfortunately it's only global, you can't target a specific rule.
There seem to be two linting rules in the electron-react-boilerplate project that are in conflict with each other.
onChange={(e: React.ChangeEvent<HTMLTextAreaElement>) =>
setSvg(e.target.value)
}
// react/jsx-curly-newline-problem
Fixing that causes
onChange={(e: React.ChangeEvent<HTMLTextAreaElement>) =>
setSvg(e.target.value)}
// eslint (prettier/prettier) problem
I have tried modifying the /configs/.eslintrc file but it has no effect. At least not on the linter running in VSCode nor the linter running as a pre-commit hook.
{
"rules": {
"no-console": "off",
"global-require": "off",
"import/no-dynamic-require": "off",
"jsx-curly-newline-problem": "off" // added
}
}
So, how can I turn off any of these off? To be able to work in VS Code without errors and to be able to commit without using the --no-verify flag.
Is it possible to override rules for specific files in TSLINT (tslint.json) like a configuration along those lines:
"overrides": [{
"files": [ "*.spec.js" ],
"rules": {
"no-unused-expressions": 0
}
}]
I wouldnt want to set a comment on each file to disable the rules - its redundant.
Update 2021;
Nowadays TSLint is deprecated and eslint should be used instead, but TSLint did support overriding rules for sub-directory, like:
{
"extends": "../tslint.json",
...
}
See: https://stackoverflow.com/a/53715541/8740349
Old answer
Seems like the only option so far is to disable them using the comment functionality.