Open neekey opened 6 years ago
We're also seeing this, but I'm not convinced it was enzyme3 that caused it - we started migrating to enzyme3 without much issue and then this issue started for us today when we upgraded a few outdated packages in our package-lock.json
one theory: watchpack
updated to chokidar
2.0: https://github.com/webpack/watchpack/releases
I can confirm that mocha-webpack
1.0.1, webpack
3.11 and mocha
5.0.1 using watchpack
1.4 works fine.
@alecf thanks for your information, but unfortunately, it does not work for me even I manually set all these modules' versions.
@neekey can you npm list chokidar
? I'm curious. On OS X, mine looks like:
├─┬ babel-cli@6.26.0
│ └── chokidar@1.7.0
├─┬ karma@1.7.1
│ └── chokidar@1.7.0 deduped
├─┬ mocha-webpack@1.0.1
│ └── chokidar@1.7.0 deduped
├─┬ nodemon@1.17.1
│ └── chokidar@2.0.2
├─┬ webpack@3.11.0
│ └─┬ watchpack@1.4.0
│ └── chokidar@1.7.0 deduped
└─┬ webpack-dev-server@2.11.2
└── chokidar@2.0.2
When I update to watchpack@latest I get:
├─┬ babel-cli@6.26.0
│ └── chokidar@1.7.0
├─┬ karma@1.7.1
│ └── chokidar@1.7.0 deduped
├─┬ mocha-webpack@1.0.1
│ └── chokidar@1.7.0 deduped
├─┬ nodemon@1.17.1
│ └── chokidar@2.0.2
├─┬ watchpack@1.5.0
│ └── chokidar@2.0.2
└─┬ webpack-dev-server@2.11.2
└── chokidar@2.0.2
And at this point, my mocha-webpack
also stops watching.
what is maybe interesting there is that mocha-webpack (and karma!) are still using chokidar 1.7 while watchpack uses chokidar 2.0 - so I wonder if having two libraries watching the same files is confusing things?
I guess have the same issue :(
@alecf
In my end, the webpack@3.11.0 uses watchpack@1.5.0 by default, which is not working.
├─┬ babel-cli@6.24.1
│ └── chokidar@1.7.0
├─┬ mocha-webpack@1.0.1
│ └── chokidar@1.7.0 deduped
├─┬ webpack@3.11.0
│ └─┬ watchpack@1.5.0
│ └── chokidar@2.0.2
└─┬ webpack-dev-server@2.11.2
└── chokidar@2.0.2
I manually installed watchpack@1.4.0, not working neither 😢
├─┬ babel-cli@6.24.1
│ └── chokidar@1.7.0
├─┬ mocha-webpack@1.0.1
│ └── chokidar@1.7.0 deduped
├─┬ watchpack@1.4.0
│ └── chokidar@1.7.0 deduped
└─┬ webpack-dev-server@2.11.2
└── chokidar@2.0.2
@alecf OK I am going to create a minimal test project to see if I can reproduce it : )
After testing with a minimal project, I found it might have something to do with https://github.com/sinonjs/sinon.
@alecf @erykpiast are you using Sinon and its useFakeTimers()
API in your projects? I found my project (the real one) 's mishap is caused by it.
So I have created a minimal project https://github.com/neekey/mocha-webpack-enzyme3-watch-mode-fail-example
it's quite pure even without Enzyme and React, with one single test case like bellow:
import { expect } from 'chai';
// import Sinon from 'sinon';
describe('[Component] Card', () => {
// uncomment the sinon and related lines of fake timers code and restart the test
// you should notice that the change watch does not work
it('Simple math test with fake timers', () => {
// const clock = Sinon.useFakeTimers();
expect(1 + 1).to.equal(3);
// clock.tick(1);
// clock.restore();
});
});
Just run npm test
you should see the result. (I found it bit weird that the first file change can be monitored but after that the watch monitor does not work anymore)
I don't have anything like that in my project 😯 I use sinon, though, for spies and stubs. I guess it doesn't really matter what part of sinon you use, it's just a matter of importing the library and including it in the bundle, isn't it?
@neekey
watchpack uses setTimout
and clearTimeout
to aggregate file system changes and mocha-webpack uses some lodash debounce calls...
Hi, I was upgrading my project to React 16 and found that once I updated the enzyme to 3.x, the watch mode stops working. I am using mocha-webpack
1.0.0-beta.1