Watch Mode Plugin: jest-runner-eslint/watch

[azz]

Combining jestjs/jest#5212 and the new Jest Watch Plugins API, it would be really cool to have:

{
  "jest": {
    "runner": "jest-runner-eslint",
    "watchPlugins": [
      "jest-runner-eslint/watch"
    ]
  }
}

Which, when an ESLint error is reported, exposes an option in watch mode:

Press F to run eslint --fix

I think it makes sense for it to live in this repo, but it could equally be a standalone repo.

I'd be happy to work on a PR if it is desired here 😄

Related: #10

[ljharb]

I think it makes sense here.

[rogeliog]

Yes, this sounds really interesting! Currently, I don't think that there is a good way of sending that information from the plugin to the runner. It would be awesome find a way that could enable these type of features!

[rogeliog]

I think I have some vague idea, I'll try to hack something today

[rogeliog]

I think having it in the same repo would make a lot of sense, given that it is a watch plugin really specific to this runner.

Here is a PoC:

There are still a couple of hiccups with the implementation, but I first wanted to be on the same page from a product perspective.

It is still pretty rough but I would love to get your thoughts 🙃@ljharb, @azz

• I added single entrypoint for the watch plugin and then a list of options that could be "modified". I hope that this would allow the plugin to scale better. The UI is similar to https://github.com/rogeliog/jest-watch-select-projects.
• I was wondering what would be other interesting options, that we would like to add to this?
  • --fix is implemented and working
  • --quiet is still mocked, and does not do anything
• Given that they both live in the same repo, we can share state way easier, which is how the plugin and runner are communicating.
• In order to achieve this there are some small changes that are needed in create-jest-runner(to pass extra options to the runner) and there are no changes required infacebook/jest.

@SimenB any thoughts on this?

[SimenB]

This is insanely awesome! I think it'd be cool to attach it to -u, but maybe not?

there are no changes required infacebook/jest

😍

[azz]

Nice! I can't think of any other ESLint flags that I would want to change during a run.

[ljharb]

What about ext?

[ljharb]

I’d also see the value in being able to enable/disable/reconfigure rules during the run.

[azz]

What about ext?

As in switching from all to just .js? What's the use case for doing that?

I’d also see the value in being able to enable/disable/reconfigure rules during the run.

That could be tricky if you want to persist back to disk. Would need to locate config file and patch it. Easy for JSON, YAML and standard module.exports = {} config files, but the JS files can be dynamic.

[ljharb]

Or from .js to .js,.jsx etc.

Why would you need to patch the config file? eslint on the CLI supports --rule

[azz]

Oh I see what you mean - ephemeral overrides, like if you want to ignore no-console. I'd use that.

[rogeliog]

Here is a quick prototype with "ephemeral overrides", thoughts?

NOTE: My prototype is just a node script, which is why it says "Back to Jest and running tests..."

[ljharb]

That looks great for rules! what about other things like parserOptions, env, globals, "settings", things like that?

[rogeliog]

I think we could extend it as much as we want, I was thinking of choosing 2 or 3 things and polish them for the first release of the watcher(and add more later). I don't have a strong opinion about what these 2 or 3 things should be. cc: Any thoughts @ljharb @azz @SimenB?

[SimenB]

I think messing with rules makes the most sense as a first iteration - parser and plugin stuff is more of a permanent change. Fine to revisit, of course, but a first iteration doesn't need it