Bring back chokidar v3

[paulmillr]

We've released Chokidar 3 in April. See my post on that: Chokidar 3: How to save 32TB of traffic every week with one NPM package

The changes are pretty big. First of all, the package is 16 times smaller and uses 15 dependencies instead of 201. We've switched to n-api, which means users won't download fsevents binaries anymore. n-api is included in every nodejs installation, and it's tiny. Directory walking has been improved massively with stream implementation of readdirp. Massive RAM & CPU improvements etc.

I really suggest switching back to chokidar. You'll receive tons and tons of bug reports otherwise, since file watching is a complex task. You're using fs.watch — it is unreliable and doesn't solve the issue. For example, i've spent a couple days this week trying to fix race conditions appearing due to async nature of nodejs IO. That's why VS Code uses chokidar.

I can submit a pull request if you'll agree.

[alexander-akait]

@paulmillr thanks for issue, we are in beta testing and nobody report about problems, maybe you can provide some examples where we potentially can be broken?

[paulmillr]

CPU & RAM usage in big projects. Did you do any tests for that? Symlink support. Support for every editor and ide e.g atomic writes.

[alexander-akait]

@paulmillr As I said earlier, we are in beta and no reports on very large projects, but i believe you. Maybe you can reproduce problems with the current version and show them?

[coreyward]

Can this issue please get some attention? This package is single-handedly holding back adoption of Chokidar (and thus, creating a bunch of issues for macOS Catalina users thanks to fsevents needing node-gyp to build, and node-gyp doesn't work right on Node 12+ on macOS Catalina) on every single webpack project. Most users aren't going to realize that watchpack is even to blame because they aren't going lockfile spelunking, but I've been bit by this over and over. I actually typically just force the resolution of chokidar to 3.3.0, but I'd prefer not to have to do that on every single project I touch.

[coreyward]

@sokra It looks like you're pretty active on this repo—perhaps you can see some reason w/r/t the above and make this possible?

[paulmillr]

My suggestion here would be to release webpack-major with min node 8.16+ or 10+ and current (webpack 4) codebase while moving "v5" to "v6". You will have more time to evaluate options. Meanwhile, all the users would receive massive performance, RAM, CPU and dependency count improvements. Most importantly, chokidar 3 won't download binaries on EVERY npm install.

[alexander-akait]

@paulmillr Sorry, it is really breaking change and can break some stuff, maybe we can do branch v3-node6 with supporting node@6 and release it, it is allow to update many stuff and avoid breaking changes, I known it is not good idea, but I can't see other ideas?

[paulmillr]

@evilebottnawi No, we cannot. N-API is only supported since node 8.0. And it was stabilized in node 8.16. That's the whole point. Without it it was not possible to create fsevents v2 that doesn't host binaries on AWS.

On a side note, the AWS S3 binary hosting account is not controlled by any of fsevents maintainers (pipobscure or me). So it could potentially distribute malware to anyone who downloads fsevents v1.

Node.js v8 stopped receiving security updates 3 months ago, on Dec 31, 2019.
Node.js v6 stopped receiving security updates 1 year ago.

I don't suggest bumping requirement to node v10. Just to node v8. And releasing a new Webpack release that would show it contains breaking change, you could name it Webpack 5.

[alexander-akait]

@paulmillr We can't do it, we already have webpack@5 and new version uses watchpack without chokidar, for webpack@4 it will be big breaking change

[paulmillr]

@evilebottnawi I don't see v5 released. So, you don't really have it. It's in beta. Beta users should know about unstable software. Just bump v4 to v5.

It's either version bump to v5, or keeping insecure dependencies which can totally distribute malware. Even worse: malware on insecure / unsupported node.js version, so a vulnerability could appear in node v6, malware would abuse it, and nothing would be done about that.

You can also bring back chokidar v3 to webpack 5 as i've mentioned in the first post. What's the point in writing your own file watcher if it won't be as performant as chokidar+fsevents anyway? You will spend 400 hours on fixing watchpack issues which will appear at some point, or you could just use chokidar like you've did before, and combine our community effort. Of course, current watchpack implementation may work for basic cases, but there's a reason why file watching is hard.

[alexander-akait]

It's either version bump to v5, or keeping insecure dependencies which can totally distribute malware.

webpack@5 is not ready yet to release

there's a reason why file watching is hard

Please provide cases as I written above

A lot of projects try webpack@5 and very few problems with watching (they fixed)

[paulmillr]

@evilebottnawi webpack@5 is not ready to release. So, bump v4 to v5 WITHOUT changes, and delay v5 to v6. That's simple. You can do the bump, or you can take responsibility if/when malware would be distributed. There is no third option.

As for "fixed" problems. Do 686 closed chokidar issues during 2012-2019 mean chokidar is fixed to you? Any software may seem without problems during some particular moment. But no software is without bugs. I won't point you to any particular issue; all i'm saying is that problems will appear, and you will spend time fixing them — a lot of time, to cover all edge cases.