Feature request: Watch mode should rerun affected specs when a file in filesToWatch changes

Is your feature request related to a problem? Please describe. I’m disappointed when I run in watch mode and I save one of my page objects that is configured in filesToWatch but nothing happens. No specs rerun.

Describe the solution you’d like I would like to analyze the dependency graph to determine what specs use a file that is saved.

Analyzing the dependency graph of all the specs that are being run is an expensive action but that’s OK (to me). It is an acceptable tradeoff compared to finding and saving the spec to trigger the next run.

Analyzing the dependency graph requires knowledge about how the compiler is configured. We don’t need to solve this problem. If we can provide sane defaults and allow the user to override the behaviour, it’ll be “good enough”.

This does not need to be a breaking change. We can allow users to opt-in by adding a new property in the config file. I would like to be able to modify the chokadir.watch 'change' event handler so we can handle filesToWatch to watch differently. We will also need to update the run method to expect one or more specs to rerun.

I’d propose implementing this in 2 phases:

1. Make it an extensible behaviour

• Add a new configuration property that is a function that overrides the behaviour of getFileListener(false). I can have a signature like (configFile, specs, fileThatChanged) => spec[]
• Refactor watcher.js to handle more than one spec being passed to run

1. Provide examples of it working, maybe, as a third-party package?

• Document how to traverse the dependency graph with Babel
• Document how to traverse the dependency graph with TypeScript
• Document the gotchas.

Thoughts on an implementation:

• We want to use a tool to parse the code instead of evaluate it to avoid causing side effects.
• The MVP demo is to parse import statements. They have constant module names. This makes it easy to build a depth-first search across a dependency graph from our specs to the file that was saved.
• We/I need to be mindful of CommonJS require and dynamic import() statements that can be variable. We’re all guilty of doing something like const env = require(`config/${env}.json`) at some point.

Describe alternatives you’ve considered

• N/A

Additional context

• At a minimum, I’m keen to make this an extensible behaviour so I can hack at night and have a slightly better developer experience in my day job. 😉
• Link back to gitter.im. Thanks for the reply Christian.
• The flow through wdio-cli/src/watcher.js:
  • If filesToWatch is in the config, we register a 'change' event listener for chokadir.watch to call this.getFileListener with passOnFile set to false
  • getFileListener returns a function that calls this.run({ ...this.args }) with no spec
  • run calls this.getWorkers using a conditional pickFn
• A great video showing an approach (without cycle detection) - https://www.wix.engineering/post/build-your-own-webpack-in-30-minutes

[christian-bromann]

@jags14385 please do!

[jags14385]

Can I pick this issue up ? Technically , would be my 2nd issue ?