Todo items for watch plugins

[rogeliog]

#5399 was merged, and it rewrites some parts of the watch mode to support third party plugins.

There are still some follow up items that need to be done.

• Add documentation for watch plugins. Add documentation for watch plugins #5895
• Allow plugins to override the usage of a key. A plugin should be able to take keys like "p" and "t" Allow plugins to override other plugins #5878
• Finish polishing the API
• Bring back typeahead. https://github.com/rogeliog/jest-plugin-filename
• Use utf-8 encoding instead of hex to make it play well with plugins. (needs discussion)
• Support non-watch mode? For CI environments, where it can access all the hooks but not the interactive prompt
• Allow plugins to be configurable... similar to Add runnerConfig option to configure runners #4278 (comment) - done in Allow watch plugin to be configured #6603

[thymikee]

Find a better name for getUsageRow(), potentialy getUsageInfo()

How about getDisplayUsage() or even displayUsage()?

[rogeliog]

There is a problem that I've been encountering while implementing Jest plugins to stress the API.

In an ideal world, I should be able to do this:

Implement the pattern mode by simply using inquirer.

Here is the code for it.

const inquirer = require('inquirer');
const ansiEscapes = require('ansi-escapes');

class PatternPlugin {
  constructor() {
    this._pattern = '';
  }

  apply(jestHooks) {
    jestHooks.shouldRunTestSuite(async testPath => testPath.includes(this._pattern));
  }

  run() {
    console.log(ansiEscapes.clearScreen);

    if (this._pattern.length) {
      console.log('Active filter:', this._pattern, '\n');
    }

    return inquirer
      .prompt([
        {
          type: 'input',
          name: 'pattern',
          message: 'Type pattern:',
        },
      ])
      .then(({ pattern }) => {
        this._pattern = pattern;
        return true;
      });
  }

  getUsageInfo() {
    return {
      key: 'e'.codePointAt(0),
      prompt: 'to enter mega filter mode',
    };
  }
}

And we could get fancier by using more inquirer features and really easily create this:

So what is the problem with this?

Jest sets stdin.setEncoding('hex'), which means that tools like inquirer don't work out of the box.
Here is my current workaround to get it to work, but it seems awkward.

  run() {
    process.stdin.setEncoding('utf8');
    console.log(ansiEscapes.clearScreen);

    if (this._pattern.length) {
      console.log('Active filter:', this._pattern, '\n');
    }

    return inquirer
      .prompt([
        {
          type: 'input',
          name: 'pattern',
          message: 'Type pattern:',
        },
      ])
      .then(({ pattern }) => {
        this._pattern = pattern;
        process.stdin.setRawMode(true);
        process.stdin.resume();
        process.stdin.setEncoding('hex');
        return true;
      });
  }

I'm not sure what the correct solution would be, but it would be awesome for inquirer to work out of the box.

• Should Jest set the encoding to utf8 and then back to hex when a plugin gets activated?

cc: @cpojer, @thymikee, @rickhanlonii, @SimenB

[SimenB]

Supporting inquirer out of the box sounds really appealing. Any downsides to switching encoding? Should a plugin be able to dictate its wanted encoding? Why do we use hex in the first place?

I also thought when I looked at your gif that it would be cool if that fancy filter also had typeahead. Thoughts on reusing logic between different plugins? Or have them extend one another.

[cpojer]

I think the encoding was just for detecting the keys. utf8 should equally work, no?

I really like this idea, btw.

[rogeliog]

Got it, thanks!

@SimenB

I also thought when I looked at your gif that it would be cool if that fancy filter also had typeahead. Thoughts on reusing logic between different plugins? Or have them extend one another.

Yes, we just need to come up with a nice interface for injecting some of the SearchSource stuff https://github.com/facebook/jest/blob/master/packages/jest-cli/src/search_source.js#L139, I was thinking of two options.

1. Inject only the file paths in a jestHooks.onFilePathsChanged(filePaths: Array<string>) and leave the rest to the plugin.
2. Find a way to access some of the searchSource queries, like findRelatedTests.

I think we should start with the first one, given that it seems less opinionated, lower level and simpler to implement.

We could probably call it from here https://github.com/facebook/jest/blob/master/packages/jest-cli/src/watch.js#L155-L180, Although I'm not sure if we should pass all the hasteFS files, or just testFiles or what would be a good interface for it.

[SimenB]

Checked off the encoding point 🎉

[SimenB]

Aaaaand the config one. Just CI env left. Not sure about that one, though

[SimenB]

@rogeliog thoughts on opening up a separate issue for the CI stuff?

[rogeliog]

Yes, let's open a separate issue... Although I think we can just close it and then open a separate issue if it is ever needed.

[SimenB]

Yeah, let's do that instead 🙂