Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: move perfectionist errors to warn #1495

Open
2 tasks done
sys13 opened this issue Apr 29, 2024 · 4 comments
Open
2 tasks done

馃殌 Feature: move perfectionist errors to warn #1495

sys13 opened this issue Apr 29, 2024 · 4 comments
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request

Comments

@sys13
Copy link
Sponsor

sys13 commented Apr 29, 2024

Bug Report Checklist

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',
	},
],
@sys13 sys13 added the type: feature New enhancement or request label Apr 29, 2024
@JoshuaKGoldberg
Copy link
Owner

馃憢 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).

"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.

@JoshuaKGoldberg JoshuaKGoldberg added the status: in discussion Not yet ready for implementation or a pull request label Apr 29, 2024
@sys13
Copy link
Sponsor Author

sys13 commented Apr 29, 2024

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
Copy link
Owner

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
Copy link
Sponsor Author

sys13 commented Apr 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request
Projects
None yet
Development

No branches or pull requests

2 participants