question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Feature Request: `info` severity level

See original GitHub issue

I 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 committing
  • info: notify the developer, but don’t want to enforce
  • off

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:closed
  • Created 7 years ago
  • Comments:16 (9 by maintainers)

github_iconTop GitHub Comments

1reaction
kasperpeulencommented, Nov 12, 2016

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.

1reaction
ben-pagecommented, May 11, 2016

The difference is only in how people interact with the output. Basically, a file containing info messages would “pass” and files with warn messages would fail. It’s especially helpful when using ESLint in an editor. error and warn 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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found