New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it possible to use Webpack watcher? #4
Comments
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 If I am wrong, feel free to correct me |
@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. :) |
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 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 |
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. |
wallaby.js looks sweet! Thanks for pointing that out. |
I think this would be great as an extension for jest. I can imagine building an |
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... |
I'm willing to make any changes necessary to jest to support webpack as an option. |
@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. |
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 intopostLoaders
section of the configuration to trigger the execution.The text was updated successfully, but these errors were encountered: