Make it possible to use Webpack watcher?

[bebraw]

It would be very neat if it was possible to run Jest tests when running Webpack in watch mode. I am aware running the tests can take a while. Regardless this could be a valuable feature helping during development.

I suppose this would mean you would have to be able to treat jest-webpack as a loader (or a plugin?) and then be able to attach it into postLoaders section of the configuration to trigger the execution.

[ColCh]

I think it's not possible for now and it's needed to patch Jest itself via PR to make it able to use provided code.

Let's dig into Jest source:

Starting point is src/HasteModuleLoader/HasteModuleLoader.js#L210:

Loader.prototype._execModule = function(moduleObj) {
// ...
  var moduleContent =
      utils.readAndPreprocessFileContent(modulePath, this._config);
/// ...
}

And utils.readAndPreprocessFileContent

var _contentCache = {};
function readAndPreprocessFileContent(filePath, config) {
  if (_contentCache.hasOwnProperty(filePath)) {
    return _contentCache[filePath];
  }
// ...
  var fileData =fs.readFileSync(filePath, 'utf8');
// ...
  return _contentCache[filePath] = fileData;
}

Since readAndPreprocessFileContent uses hardcoded fs.readFileSync and private variable _contentCache for cache, it's not possible to mock file content loader and\or inject own code from webpack side.

If I am wrong, feel free to correct me

[bebraw]

@ColCh Can you open an issue about this at the Jest side? It would be just awesome to have this fixed.

I thought about the problem of long test execution. I suppose ideally it should be possible to execute just tests that are relevant to the touched code. Let's say you are developing an individual component. In that case only component tests should be run. I'm aware this isn't an easy problem to solve. Just some food for thought. :)

[ColCh]

Yeah, this project (jest-webpack) has same issue as karma-webpack - both are working as preprocessor. That forces webpack runtime to reload for every file.

I will try to contribute to Jest on it.

Oh nice feature! It reminds me wallaby.js killer feature (no ads).

Also this is similar to mocha's Exclusive tests feature.

I can give you some unasked advice for testing, if you don't object. This if from my experience of experimenting. I hope it will be useful.

You are testing React components, right? Then you are able to test them inside of jsdom + mocha environment.

Mocha is pretty fast itself and mocha-loader for webpack make it possible to execute tests inside live browser like Chrome (and node environment as well, with enhanced-require).

[bebraw]

You are testing React components, right? Then you are able to test them inside of jsdom + mocha environment.

Yeah. I've read of Mocha based approach. Thanks for bringing it up. :)

I'll see if I can cover these topics in my Webpack/React book. Testing deserves a chapter of its own.

[bebraw]

wallaby.js looks sweet! Thanks for pointing that out.

[cpojer]

I think this would be great as an extension for jest. I can imagine building an fs abstraction that you can swap out in jest – do you wanna send a pull request for that?

[ColCh]

Yep, when I will be some kind of free. Currently I'm very busy with work :(

I think, FS abstraction will not help - webpack will continue to reload entrie build runtime. Thats slow...

[cpojer]

I'm willing to make any changes necessary to jest to support webpack as an option.

[richardscarrott]

@ColCh I agree, I don't think the bottleneck is writing to disk as, at least from my tests, the performance benefit of using memory-fs is marginal at best.

In Jestpack I opted not to use Jest's preprocessor config as it's run per test which means the Webpack build cannot be optimised (e.g. by using the CommonsChunkPlugin) because Webpack isn't aware of the entire codebase. In addition it's hard to then take advantage of Webpack's fast incremental builds during development because you'll have as many compiler instances as you have tests.