Giters

microsoft / vscode-eslint

VSCode extension to integrate eslint into VSCode

Repository from Github https://github.commicrosoft/vscode-eslintRepository from Github https://github.commicrosoft/vscode-eslint

Can I only auto-fix all error and do not auto-fix warnings ?

benpigchu opened this issue · comments

commented

Some warnings is auto-fixable but we do not want to fix it, like "prefer-const" .
Can we just fix errors when we auto-fix all ?

commented

@benpigchu do you know if this is possible on the command line when calling eslint --fix?

commented

@dbaeumer NO, but it seems that we can do it with the eslint node.js api.

commented

Cool. Interested in working on a PR to support this ?

commented

Yes, in general it'll be great to be able to filter some rules specifically from auto-fixing.

It was discussed also at ESlint, and it's the recommended approach (solve it on editor side).
See the thread

commented

@medikoo thanks for the pointer.

commented

This VSCode config was the solution for me.

  "eslint.options": {
    "rules": {
      "no-debugger": "off"
    }
  },

Pre-commit hook / CI still error on debugger. VSCode doesn't auto-fix 🤘

commented

Would something similar to this work here? microsoft/vscode-tslint#231

Edit: And is the priority on excluding which rules autofix?

commented

@adenflorian having autoFixOnSave to be a string[] alternatively and then only autofix the onces listed makes sense to me.

commented

Hi, It is better for me to specify rules that disable auto-fix like linter-eslint (atom)! I think it is hard to set all of the other fixable rules...

commented

@adenflorian @TasukuUno comment makes sense to me. May be we can use the ! to negate strings like in git config files.

commented

@dbaeumer What should happen if you have this config?

autoFixOnSave: [
  "semi",
  "!quotes"
]

Mixing includes and excludes complicates things a bit, so I made a table to help define the behavior of whatever we decide. Populated with my current implementation. I'll come and think about this more later.

autoFixOnSave behavior
false never auto fix on save
true auto fix everything on save
array auto fix only rules in the array on save

Edit: Can we use an object for a config property? Like this?

autoFixOnSave: {
  "mode": "exclude",
  "rules": [
    "semi",
    "quotes"
  ]
}

Maybe different modes can be off, include, or include, or something along those lines.

commented

@davidvalachovi good questions. I would say the first entry defines whether it is include or exclude. Mixing them does indeed make no sense.

Technically a setting can be a complex object property. But it makes using the feature more complex to setup.

commented

@dbaeumer Like this?

autoFixOnSave behavior
false never auto fix on save
true auto fix everything on save
array with 'mode=include' as first entry auto fix only rules in the array on save
array with 'mode=exclude' as first entry auto fix all on save except for rules in array
array with any rule as first entry default to auto fix only rules in the array on save

I decided on mode= so as not to possibly conflict with any eslint rules.
What do you think about the default behavior? Should it throw an error instead?

commented

@dbaeumer Another idea, after looking at linter-eslint for atom.
Have autoFixOnSave work the way I have it in my PR (#325), and have a separate config property called rulesToDisableWhileFixing which will be an array of rules that will never be auto fixed (whether on save or on executeAutoFix), and overrides any rules in autoFixOnSave.

commented

Having two properties is not appealing to me. I would go with this #208 (comment) proposal then. Howver Nesting include / exclude rules makes sense if we provide wild cards. So something like

[
    "se*",  // matches all rules starting with se
    "!semi", // exclude the semi rule
]

I don't know the ESLint rule names. But would something like this make sense?

commented

@dbaeumer I'm actually not a fan of my suggestion using mode=include as the first element in the array to control the behavior. Any chance you would go for the object idea? I think I would be able to write an enum to give the user autocomplete for the mode property, where that would be a bit harder, if even possible, to do with it being the first entry in the array.

autoFixOnSave: {
  "mode": "exclude",
  "rules": [
    "semi",
    "quotes"
  ]
}
commented

May be we first should agree on what we want to provide and then come up with a syntax on how to best describe this in JSON. In general I see the following:

  • we have a start set of rules from which we want to exclude a part
  • we have an empty set into which we want to add / include rules.
  • for an inclusion description we can specify exclusion again (only makes sense if we support globbing)
  • for an exclusion description we can specify inclusions again (only makes sense if we support globbing)

Side note: internally the start set could be '*' if globbing is supported

Something like

{
    rules: [
       ....
    ],
    include: [
       ....,
       exclude: [
          ....
       ]
    ],
    exclude: [
       ....
       include: [
       ....
       ]
    ]
}
commented

Given the above idea we could do the following: if rules is missing we start with an empty set and only includes are allows. If rules are given then only exclude is allowed.

commented

Why not introduce a new property, eslint.rulesToDisableWhileFixing:[] and leave the semantics of autoFixOnSave unchanged?

Also, as an user that is constantly hit by this ""bug"", I think it is far more important to come with an API to solve this ASAP, and maybe deprecate it in the future if/when we have a better API. Because we won't get the perfect API anyway and eventually we will have to deprecate it anyway, no matter how much time we spent discussing about the "perfect" API.

commented

Would this allow us to do the opposite--ignore prettier/prettier for linting/underlining but have it run when saving?

commented

Everything works like a charm (at least for my personal experience) when we have autoFixOnSave setting with an array of strings specifying which rules you want to automatically save.

This has worked in another Typescript project (TSLint already has this feature) and I have only to thank for this.

And another plus, this feature is already implemented in the PR 325 (commit).

Really looking forward for this.

commented

Chiming in to say this is on my wishlist as well, particularly any variant where you can exclude rules that are set to warn.

My employer's codebase has gone through some changes to linting standards over the years. If I work on an older file, the auto-linter will make it light up with diffs that aren't very meaningful or useful. I'd prefer if it only fixed those violations that make it refuse to compile.

commented

you can use eslint-plugin-no-autofix:
eslintrc:

{
  "plugins": ["no-autofix"],
  "rules": {
    "prefer-const": "off",
    "no-autofix/prefer-const": "error"
  }
}
commented

@aladdin-add thanks a lot for the pointer.

I would argue that we can close the issue since having a solution in ESLint itself is preferable over a custom solution in the extensions. Any objection ?

commented

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

commented

@aladdin-add I'm unable to use that plugin.

This config works (no autofix):

module.exports = {
    "root": true,
    "plugins": [
        "no-autofix"
    ],
    "parserOptions": {
        "ecmaVersion": 6,
    },
    "rules": {
        "prefer-const": "off",
        "no-autofix/prefer-const": "warn",
    }
}

After adding just one more rule (that should be autofixed):

module.exports = {
    "root": true,
    "plugins": [
        "no-autofix"
    ],
    "parserOptions": {
        "ecmaVersion": 6,
    },
    "rules": {
        "prefer-const": "off",
        "no-autofix/prefer-const": "warn",
        "prefer-template": "warn"// here
    }
}

ESLint just completely stops: ESLint: Fixable rules should export a `meta.fixable` property.. Please see the 'ESLint' output channel for details..

Error: Fixable rules should export a meta.fixable property.
at Object.report (...\node_modules\eslint\lib\linter.js:724:35)
at checkForStringConcat (...\node_modules\eslint\lib\rules\prefer-template.js:272:25)
at listeners.(anonymous function).forEach.listener (...\node_modules\eslint\lib\util\safe-emitter.js:45:58)
at Array.forEach ()
at Object.emit (...\node_modules\eslint\lib\util\safe-emitter.js:45:38)
at NodeEventGenerator.applySelector (...\node_modules\eslint\lib\util\node-event-generator.js:251:26)
at NodeEventGenerator.applySelectors (...\node_modules\eslint\lib\util\node-event-generator.js:280:22)
at NodeEventGenerator.enterNode (...\node_modules\eslint\lib\util\node-event-generator.js:294:14)
at CodePathAnalyzer.enterNode (...\node_modules\eslint\lib\code-path-analysis\code-path-analyzer.js:632:23)
at nodeQueue.forEach.traversalInfo (...\node_modules\eslint\lib\linter.js:751:28)

Extension Version: 1.8.2
"eslint": "^5.15.1",
"eslint-plugin-no-autofix": "0.0.1",
commented

@usernamehw thanks for the feedback, I can repro it, will publish a patch to fix it! 😄

commented

@usernamehw could you try eslint-plugin-no-autofix@0.0.2?

commented

@aladdin-add, working great now 👍