Via #855, concern that existing tools consuming default formatters will break - this issue won't affect that, it would be the same output just broken up instead of one big lump at the end.

This has come up before and I'm just not sold on the usefulness especially given the significant changes required to make it work. Some formats would be okay (stylish, compact), some would not because they need to have leading and trailing pieces (any of the XML-based formats or the third-part party JSON formatter).

I just don't see an easy way to support this change without a fundamental rewrite of how formatters work, and without some clear benefit from doing so, I'm inclined not to make such changes.

The formatters would not need massive changes - a streaming interface with 'message' (or 'file') and 'end' events would allow existing formatters to just subscribe to the 'end' event to start off with, and no further changes. Then formatters for which intermediate output makes sense (not including e.g. XML) could also consume 'message'. We could also probably find a way to just augment the existing interface and still keep it backward compatible.

It would be very useful for larger projects, for which there is very little running information on the progress of eslint despite it being one of the longer-running and more important build tasks.

For instance, one way would be to change the formatters to this:

module.exports = {
    'end': function(results) {
        ....
    }
}

And then check to see if the formatter is a function or an object. If it's a function, call it directly when the results are complete, otherwise fire the events on the object as they come up. cli-engine would have to take in an eventing interface or a callback for the traversal but that would be simple.

Again, I'm not convinced there's enough value in doing this work. There's almost always a way to make something work, that's not the issue. What you've described is just a starting point, there would many other details to work through. I just don't see the work as having a high enough payoff for making the changes at this point, especially when there is high-priority work to get done.

As long as you agree with the principle of it I'm happy to do the work. It is somewhat important to me as someone using eslint in a context where it takes several minutes to run, and who receives complaints every so often from devs not sure if the build has finished or hung or what. I'd also be happy to focus on higher-priority things first and come to it later, but I'm not sure what has higher priority and what doesn't. Would you consider things explicitly tied to milestones higher priority?

Those issues assigned to milestones are considered highest priority, in this case milestone 0.8.0 had the highest priority. The reason why I'm fighting to deprioritize random things that aren't bugs is because there aren't enough people working on this project to do those and also move the project forward against its roadmap. The more random features get jammed into a release, the more fragile it becomes and ultimately creates a lot more work for me (0.7.1 was just terrible).

Honestly, once plugins are in, the roadmap is pretty open for whatever random other stuff pops up. I just don't want to get distracted by nice-to-haves when there are important need-to-haves not yet done.

(Rules are basically freebies because they exist on the farthest edge of the tool.)

FWIW, I tried to explain this in the contributor guide, though I'm sure most people don't read the whole thing.

Okay, thought about this some more. I feel comfortable slotting this for 0.9.0.

If filename is passed in every message, i'd suggest to add methods flush and close. If filename is passed only for groups, ththen i'd suggest to add methods file (new group), append (new message), close (done).

Also, if change will be breaking, may be it worth to rename formatters to reporters.

This won't be a breaking change. We'll just add another type of formatter.

@nzakas, Probably, we means different things with "breaking". Final output will be the same. But API can be different. Is it bad ? AFAIK 0.6 and 0.7 required to update projects, depending on eslint, at least due rules change (was "breaking" in my mind).

Actually, live updates are required for console (default) reporter. For other reporters code simplicity is more preferable.

About feature in generail - live updates are very important for usability. When you tune new big project first time, eslint can hang for a very long interval, until you properly set ignores & rules. Live update will partially solve this problem.

Also, i'd suggest to add "verbose level" cli option, useful for setup check - show each linted file name even if it has no messages. This feature depends on live update implementation and can be done at once. I think, it worth adding to base spec, instead of separate ticket.

@puzrin breaking means that people who already use ESLint need to change something when upgrading, which means that something previously worked but now does not. We can't change how formatters are defined because there are already third-party formatters and we would break them. What we can do is add another type of formatter that can do this progressive output.

And as I've mentioned before, please open new issues for each suggestion you have. They will get lost otherwise.

I've created separate ticket as you suggested, but i don't like ready recipes until problem is formalized. Creating solutions from bottom breaks designs principles. Prior to go for implementation, we should have agreement about problem, that we try to solve.

IMHO, in this case the main problem is long eslint hangs on run. And i'd like to discuss possible examples from real life, prior to create one more ticket with solution. Without live updates suggestion about verbose level will have completely different effect, not relevant to initial idea. You could see similar situation in ticket about .yml extention - solution was formally correct, but not acceptable on practice.

@puzrin issues aren't just for solutions, they are for problems in need of discussion. You don't need to have a solution in mind, it's perfectly fine to file an issue describing the problem and asking for input.

If you start talking about other topics on an already-existing issue then that discussion can both derail the point if the issue and can easily get lost, especially when the issue is closed.

+1

Closing for lack of activity

Lack of activity !== useless. It's not good that eslint can hang for a noticeable time after run.

Would love to see something like this along with a progress bar.

activity += 1

I could really use this right now trying to run ESLint on a slow machine. Is ESLint doing something or is it hanging?

+1

The team has limited resources right now, and most of the members are focused on other priorities, like the v4 release and the re-write of the indent rule.
Unless someone from the community is willing to get the ball rolling on this with a proposal for a solution, I'm not sure I see this moving forward for the near-future.

My problem with this was that I was working on .eslintignore, so I solved it just by adding --debug option to see that work is in progress and not just stuck.