Allow to exclude certain rules from code formatting

[pvdlg]

While developing it's often useful to comment some code or add .only/.skip to some tests.

Rules like capitalized-comments, ava/no-only-test or ava/no-skip-test create friction during development when formatting the code on save with vscode-xo.

For example it's impossible to add .only to an AVA test because it will be removed automatically on save.

It would be nice to have an option in the plugin to ignore some rules when auto formatting, similarly to what atom-linter-xo does: https://github.com/xojs/atom-linter-xo/blob/master/index.js#L55

[sindresorhus]

Our Atom linter plugin has an option for this, which defaults to the mentioned rules: https://github.com/xojs/atom-linter-xo/blob/3645b74ba8820b99afff36419c4798ad1da12690/index.js#L55

However, honestly, I agree with you. They can be annoying and auto-fixing doesn't make much sense for them, in hindsight. Maybe we should move those rules to use the ESLint suggestions API instead of auto-fixing? If you agree, I can open some issues.

[pvdlg]

That sounds a great idea!

Closing this issue as the suggestion API is a better solution!

[sindresorhus]

avajs/eslint-plugin-ava#281

But I just realized that we don't own capitalized-comments, so we cannot do anything about that other than possibly disabling it... There was this eslint/eslint#12561, but of course it was closed by the annoying issue bot. Ideas?

[pvdlg]

I guess we could implement our own version in eslint-plugin-unicorn...

[sindresorhus]

We could actually just create a rule that is bundled in XO that just implements it without any options, and only does what we need: https://github.com/xojs/eslint-config-xo/blob/06e4e1416bdbf2df56984adca8039683ebad735c/index.js#L258-L267

If you agree, I can open an issue on XO.

[pvdlg]

Not sure how to do that, but if you think it will work, let's do it!

[droobertzka]

If no rules are specified in a project's xo config, disabling rules like capitalized-comments in the project's vscode settings (i.e. xo.options.rules) works well. Auto-fix doesn't capitalize blocks of commented code, and the rule still gets enforced during githooks, CI, etc. Unfortunately, if rules are specified in your project's xo config (this seems to be the case more often than not for me), they get clobbered by the rules in the vscode settings.

@pvdlg @sindresorhus - This vscode extension already appears to inherit projects' configs (e.g. from package.json or xo.config.js). Is it intentional that rules are overwritten wholesale as opposed to merged? I'd be happy to open an issue and/or create a PR, though I may need some direction for the latter.