search

rizowski / eslint-watch

ESLint with simple watching capabilities
https://www.npmjs.com/package/eslint-watch
MIT License
196 stars 29 forks source link

Unresponsive in certain situations #122

Open brokentone opened 7 years ago

brokentone commented 7 years ago

Environment

Basic Description of the problem

Watch feels very unresponsive when eslint is running. Linting is unpredictable due to keybindings.

How to reproduce it

  1. Command: esw --watch --ext .js --ext .jsx .
  2. hit the return key 3x
  3. ctrl+c
  4. ... nothing for 3x the run of eslint (which in my case is near 1m)
  5. process ends

Debug output:

Somewhat irrelevant

Thoughts...

First off cool tool, I'm trying to work this into my build flow right now, but this concern I'm raising is preventing me at the moment. I think the issues are 4 or 5:

  1. Keybinding is not documented from what I read. That's a fairly aggressive thing to do (taking over the return key) without notice. Suggestion: Add it as a feature to the documentation.
  2. Restarting the eslint currently does not provide any output until it is complete, making it feel unresponsive. Suggestion: Output the current debugging message "Restarting eslint at user request:" or something...
  3. Again with the aggressive keybinding (particularly as I'm attempting to run through npm-run-all, I do not want my keys bound by any of the subprocesses. Suggestion: I would need the option to disable. In fact, with this being undocumented right now, I would recommend that it's disabled by default, and a flag could enable it.
  4. Spawn should is currently done sync, this combined with the key binding, prevents any interrupts until the child process (eslint) is complete, which is not desired behavior. Suggestion: Removing binding (item 3) should help with this, but this really should be reimplemented in the non-sync way. If you wanted to keep your code procedural rather than switching large parts to CPS, I imagine you could get away with generators (or async/await/yield if you were willing to support that bleeding stage of a feature).

I would be willing to submit PRs for most / all of the above if the project is interested.

rizowski commented 7 years ago

@brokentone thanks for submitting this. I won't be able to review this or your PRs for a couple of days. But once I get back to an area that I have consistent internet I'll be sure to review these and get back to you on them.

rizowski commented 5 years ago

This has not been addressed in V5 but it should be an easy addition.