Allow plugins to override other plugins

[rogeliog]

This PR allows third party plugins to override the "key" that an internal plugin is using.

Contributes to #5478

Summary

Test plan

[rickhanlonii]

I'll review asap - and I can handle the merge conflict too

[SimenB]

This is amazing, shaping up! :D

[SimenB]

Should the base class every watch plugin extends have a getUsageInfo function which returns null or empty string so you don't have to check for its existence?

[rogeliog]

I think this will make the implementation easier, but I'm worried about making the API for the consumers a bit harder. Given that there will be plugins that do not implement it

[rogeliog]

I sometimes wonder if we should just move everything to be a jest hook, and make the whole API just around jest hooks

class MyPlugin {
  apply(jestHooks) {
    jestHooks.run(/* ... */);
    jestHooks.getUsageInfo(/* ... */);
    jestHooks.testRunComplete(/* ... */);
    jestHooks.fsChange(/* ... */);
    jestHooks.onData(/* ... */);
    jestHooks.shouldRunTestSuite(/* ... */);
  }
}

instead of

class MyPlugin {
  apply(jestHooks) {
    jestHooks.testRunComplete(/* ... */);
    jestHooks.fsChange(/* ... */);
    jestHooks.shouldRunTestSuite(/* ... */);
  }

  onData(/* ... */) {
    /* ... */
  }

  run(/* ... */) {
    /* ... */
  }

  getUsageInfo(/* ... */) {
    /* ... */
  }
}

Seems like the plugin architecture is working already, which means that changing to an API like the one above should not be that hard.

This means that the apply method is the only method that exists in the class and everything else is a jestHook. Seems that if we would like to make this changes it is better to do them now than later.

thoughts? Which API seems cleaner? Which API would be easier to document?
@rickhanlonii @orta @cpojer @SimenB

[cpojer]

I'm worried about the first API being too open. There are other open source tools out there that allow people to do anything they want in a plugin and it generally causes the entire system to slow down considerably. I think we should stick with a more limited API that guides user to build plugins in the way we expect them to be built. Of course, it's still possible to completely break out of that system and do harmful slow things but it is less likely to happen.

[rickhanlonii]

+1 to @cpojer and I like that the current Watch Plugin API is similar in structure to the runner and reporter - implement a class with a specific structure

[orta]

+1 - slow and deliberate improvements as we need them, I think this looks great

[rogeliog]

Perfect! 😄

[cpojer]

OMG it's happening.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.