🚀 Feature: move perfectionist errors to warn

[sys13]

Bug Report Checklist

• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

When writing code I usually interpret the red error squiggles as something that I've done wrong, questioning if there's something I need to change. The perfectionist plugins often show errors, but I don't need to fix anything, rather just save and let the auto fix deal with it. In this case, I'd prefer a warning, more as a prompt to save.

perfectionist/sort-intersection-types
perfectionist/sort-objects

Additional Info

could add:

'perfectionist/sort-intersection-types': 'warn',
'perfectionist/sort-objects': [
	'warn',
	{
		order: 'asc',
		'partition-by-comment': true,
		type: 'natural',
	},
],

[JoshuaKGoldberg]

👋 thanks for mentioning @sys13!

red error squiggles

Interesting, what editor are you using? For VS Code, this template switches all ESLint reports from red (error) to yellow (warn).

create-typescript-app/.vscode/settings.json

Line 16 in 28ac87a

"eslint.rules.customizations": [{ "rule": "*", "severity": "warn" }],

The problem with warnings in ESLint is that they have a bad habit of being ignored by developers over time. eslint/eslint#16696 -> eslint/eslint#16882 has some good discussion around that. Which is why I'm a big fan of showing the reports as warnings in the UI but treating them as errors in CI.

[sys13]

Ah, thanks @JoshuaKGoldberg - I don't use the full project (just bolted in the eslint rules, so much good work there) so I missed the vscode setting.

I do like having errors for things that I need to fix while I'm coding, and warnings for things that the editor can auto fix. Prefer not to wait until CI, as I have to go back and get in context to make the fixes. As an idea maybe you can have a minimal/maximal setting for how to approach things, instead of a one-size-fits-all.

[JoshuaKGoldberg]

minimal/maximal setting for how to approach things, instead of a one-size-fits-all

Can you say more? What kinds of things would you want to change around with those settings?

Slash, is https://github.com/JoshuaKGoldberg/create-typescript-app/blob/28ac87a6fbd116602c55fc0bdffa485119060dc3/docs/Tooling.md different from what you're looking for?

[sys13]

I think what I'm proposing is turning off "eslint.rules.customizations": [{ "rule": "*", "severity": "warn" }], for the Everything level, and turning some things into warn (like perfectionist) to still not be too alarming while in the editor.

[JoshuaKGoldberg]

Ok! I tried this out and ... it's a nice idea, but I really couldn't get used to the blue squigglies in VS Code 😅. It's a pity. I think it makes a lot of sense to separate stylistic lint complaints from functional ones. But:

• There are arguably quite a few other stylistic-only lint rules enabled by default - it'd be a lot of code to have them all be given the blue squiggly treatment
• VS Code just has the solid color squigglies, only the standard blue+yellow+red colors we're used to...
  • In a perfect world they'd add more rich colors the way e.g. Webstorm has more squiggly options. Offer code mark styles and gutter marks microsoft/vscode#9209 is the closest existing issue I can find.

So, thanks for filing, but the underlying tech isn't there yet. 😞