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.

Add a git-ratchet formatter

See original GitHub issue

The version of ESLint you are using. Any

The problem you want to solve. I want to use ESLint to report on problems in my existing codebase and am fine with existing violations existing, however I would like to prevent additional violations from being added to the codebase.

For example, I would like to enable the “semi” rule so that semicolons are required, and currently have 100 violations in the codebase. However if someone adds a line of code without a semicolon so that there are now 101 violations, I would like my CI build to fail.

Your take on the correct solution to problem. git-ratchet can be used to keep track of measures in a codebase, it can then report that a metric has increased and a CI build can be failed.

Its reporting format is very simple: rule-name,N where N is the number of violations for that metric.



Note that this reports on total violations found, not on violations per file.

Are you willing to submit a pull request to implement this change? Yes, I’d just like to gauge the interest and suitability.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

platinumazurecommented, Jun 18, 2019

I don’t think we’re likely to accept new formatters at this point unless there’s a clear need for it in order for ESLint to work with popular integrations. Others on the team might disagree, though.

As noted, you can publish the formatter to npm and then others can still get the benefit. 😄

eslint-deprecated[bot]commented, Jul 19, 2019

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How do I run a code formatter over my source without ...
Then don't use git filter-branch — just run the formatter, add and commit. Or if you want to modify the last commit in...
Read more >
Improve code formatting on every commit - Medium
The intention of this post is to give a solution to such formatting issues right at the stage of every commit. Doing this...
Read more >
Using a Code Formatter - WPILib Docs
Using a Code Formatter . Code formatters exist to ensure that the style of code written is consistent throughout the entire codebase.
Read more >
git-format-staged - npm
You want to make sure that everyone working on the project runs the formatter, so you use a tool like husky to install...
Read more >
Check formatting locally and on GitHub Actions with pre commit
4 Tools to Format & Check your Code with Pre- Commit | Flask and Python Backend #6. The Dev World - by Sergio...
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 Post

No results found

github_iconTop Related Hashnode Post

No results found