Feature Request: `info` severity level
See original GitHub issueI love that ESLint supports multiple severity levels. This is a huge advantage over many other linters. I’d love to see this developed a little further. I think adding an additional info
severity level would be a good improvement. Basically this would be a less severe than ‘warn’ . It would be used to notify about common issues that you don’t want enforced and treated as a failure.
So the levels would look like this:
error
: should be fixed immediately (pseudo compile-time error)warn
: may be ignored during prototyping, but should be fixed or disabled before committinginfo
: notify the developer, but don’t want to enforceoff
There’s secondary benefit to info
as well. If a rule does not totally conform to your standards (for me curly
is an example), setting the rule to info
would allow you reap some benefit from the rule without having to update all of your code.
Issue Analytics
- State:
- Created 7 years ago
- Comments:16 (9 by maintainers)
Top Results From Across the Web
Severity levels and response times for support requests
Wondering what Severity means when you submit a support request? Learn how the different severity levels are defined, and which one you...
Read more >Severity levels: Definition & Examples - Kaseya HelpDesk
Severity 1 (highest) business impact requests that require an immediate response or direct help of technical support specialists may be processed out of...
Read more >What are case Severity levels, examples and support effort?
Severity level describes the level of the impact to your system. It shows how service levels are affected by the current state of...
Read more >VMware Severity Definitions and Response Targets
The severity of the problem and the service levels of the support program that you purchase determine the speed and method of our...
Read more >DevOps best practices: add severity levels to alerts
Severity levels are an important concept in alerting to aid you and your team in properly assessing which notifications should be prioritized.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Just saying, that I would also really love an extra level. All the argument against this seem with the idea that eslint is mostly used on the command line. But if you use it in an editor, it is very common and useful to have more levels of severity.
The difference is only in how people interact with the output. Basically, a file containing
info
messages would “pass” and files withwarn
messages would fail. It’s especially helpful when using ESLint in an editor.error
andwarn
messages should be intrusive to encourage them to be fixed,info
messages should not be intrusive. This is how the built-in inspections in most IDEs work.