webpack@4, node@13, Mac crashes when compiler.watch().close() #10037
Comments
|
Have the exact same problem... |
|
To be honest, I wanted to re-check whether this is still an issue with fsevents@1.2.11 (which added Node 12 compatibility)... I use a Linux machine, so I need to get my hands on a Mac. |
|
I've re-checked the above instructions... still crashes on Mac and Node 13. |
|
What is version node? |
|
Checking in from the Nuxt.js issue that was just linked. Node.js 13.5.0 with macOS 10.15.2 here. |
|
Same issue here node 13.2, npm 6.13.4, macOS 10.15.2 |
|
Can you try to update node to latest version? |
|
just re-tested on Node 13.6.0 with latest Btw, I'm not certain it's a Node issue. Mac is the only platform where |
|
@evilebottnawi just like @AviVahl said, it's the exact same; from what I could tell looking online, it looks like it's a chokidar/fsevents issue; I first noticed it in using https://github.com/JeffreyWay/laravel-mix, which uses chokidar version 2.0.x and webpack 4 still; Looks like v3 is out... |
|
Can confirm. Updated to node 13.6.0 and the error still occurs. |
|
The same error. Node v13.6.0 |
|
I am testing with v13.8 now. |
:( |
|
node v13.8.0 However when closing the node I receive the error again. |
|
For webpack 4 we can't upgrade to chokidar 3, as this would be a breaking change. This would need to be fixed in a chokidar for webpack 4 to benefit from it. I also see these errors randomly occuring in the CI build. For webpack 5 we migrated away from chokidar and native dependencies. I no longer see these errors in the webpack CI builds. |
|
i'm getting this as well on node 13.8 with karma and karma webpack. was fine on node v11.12 |
|
Failing as well |
|
Am also getting the below error. npm server crashes after few mins connecting to mongo db. any idea why this is ? Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187. |
|
Anyone experiencing a problem please read - fsevents/fsevents#314 Briefly - not fixable, not sure if even I send a fix for it, it will be merged. Good news - webpack@5 doesn't use |
|
That's a shame, because this started failing with the newly released Node 12.16.2 as well. :( |
|
@AviVahl You can open a new issue, maybe when the number of issues becomes more, they will change their minds |
|
Same experience : Node v13.8.0, Mac Catalina OS |
|
Edit: nope, this not work. This is weird, some build finishes successfully randomly. I fixed it by forcing No anormal behaviour seen so far. |
|
Same here (using Expo bare-minimum). |
|
I'm using
|
|
Issue got replaced with another: Happens for mocha-pup for all node 10/12/14 on Mac. The new issue appears to already be documented here: fsevents/fsevents#325 Now's the twist. when I tried to reproduce in a separate project using Node v12.16.3 (npm v6.14.4), I've encountered what seems to be a bug in how npm handles optional dependencies. If I: mkdir testing
cd testing
npm init -y
npm i webpackAnd then look in the "fsevents": {
"version": "1.2.13",
"resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.2.13.tgz",
"integrity": "sha512-oWb1Z6mkHIskLzEJ/XWX0srkpkTQ7vaopMQkyaEIoq0fmtFVxOthb8cCxeT+p3ynTdkk/RZwbgG4brR5BeWECw==",
"optional": true,
"requires": {
"bindings": "^1.5.0",
"nan": "^2.12.1"
}
But if I run the same set of commands, just adding chokidar to the install command: mkdir testing
cd testing
npm init -y
npm i webpack chokidarThen the "fsevents": {
"version": "1.2.13",
"resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.2.13.tgz",
"integrity": "sha512-oWb1Z6mkHIskLzEJ/XWX0srkpkTQ7vaopMQkyaEIoq0fmtFVxOthb8cCxeT+p3ynTdkk/RZwbgG4brR5BeWECw==",
"optional": true
},Without the It seems the existence of another The above behavior reproduces consistently (try it yourself) and leads me to believe that depending on which dependencies are in your project, you might experience one of two behaviors:
This also accounts for why some people no longer see the crash, and others do (in comments above). |
|
You should ask maintainers to upgrade to fsevents v2. |
|
@paulmillr already answered is in this thread: #10037 (comment)
Well, TBH, not really stuck... we've added workarounds in several of our code-bases to force no watching when in "single-run" mode... :/ This can get a bit hairy, because sometimes it's abstractions like These are just two examples from open source projects. I hate these workarounds, but we are already using Node 12 in production and started supporting 14. We cannot be held back by such issues. |
|
@AviVahl not really. There is an effort to upgrade to chokidar 3, maintainers merged pull request/s already. Ask them to release new versions asap. |
|
Alright, so the latest releases of |
|
@AviVahl I also dislike that. Technically chokidar2 should only be installed when node<8, but npm seem to ignore that. Works fine in yarn. |
|
@sokra see this comment on "removing chokidar in next major version". The file watching task is not as simple as it looks. |
|
@sokra both npm@6.14.4 (comes with latest node 12/14) and yarn@1.22.4 (current "latest" for yarn) warn about and install duplicate Alternative possible solution: All this juggling of dependency versions is starting to get out of hand. You end up using older versions of packages just to keep supporting an unsupported Node version. Meanwhile, consumer projects using LTS versions of Node end up having duplicate dependencies, weird post-install errors, and failing CI builds due to runtime errors (original issue). I mean, we've been dealing with this for quite a while now. Consumer projects started having the original issue over 6 months ago. Having said the above, I wanna add that I appreciate your hard work, and will respect whatever decision you end up taking here. |
|
We're not going to run out of numbers any time soon, releasing Webpack 5 just to drop node 6 support seems reasonable. |
|
Alright, I am closing this issue, as the reported crash should now be fixed (make sure your project has watchpack resolved to v1.7.2 or above). There's a separate new issue (postinstallation errors) which is expected to resolve itself with |
Motivation ---------- fixes mswjs#188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on MacOS with some regularity. That is because it depends on chokidar 2 which uses the `fsevents` api which has a [crictical bug][2] on MacOS. Approach -------- This manually forces all modules to use chokidar 3 which does not use the `fsevents` module at all. While this does trigger a semver violation because webpack 4 depends on chokidar 2, the API is apparently similar enough that all the tests pass. It does however give rise to a warning in the console upon installation of depedencies via a `yarn`. This resolution can be removed once an upgrade is made to webpack 5 or to a different depedency bundler like [parcel][3] or [rollup][4]. Learning -------- * [Selective dependency resolutions ][5] [1]: webpack/webpack#10037 [2]: fsevents/fsevents#314 [3]: http://parceljs.org [4]: https://rollupjs.org [5]: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/
Motivation ---------- fixes mswjs#188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on MacOS with some regularity. That is because it depends on chokidar 2 which uses the `fsevents` api which has a [crictical bug][2] on MacOS. Approach -------- This manually forces all modules to use chokidar 3 which does not use the `fsevents` module at all. While this does trigger a semver violation because webpack 4 depends on chokidar 2, the API is apparently similar enough that all the tests pass. It does however give rise to a warning in the console upon installation of depedencies via a `yarn`. This resolution can be removed once an upgrade is made to webpack 5 or to a different depedency bundler like [parcel][3] or [rollup][4]. Learning -------- * [Selective dependency resolutions ][5] [1]: webpack/webpack#10037 [2]: fsevents/fsevents#314 [3]: http://parceljs.org [4]: https://rollupjs.org [5]: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/
Motivation ---------- fixes #188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on MacOS with some regularity. That is because it depends on chokidar 2 which uses the `fsevents` api which has a [crictical bug][2] on MacOS. Approach -------- This manually forces all modules to use chokidar 3 which does not use the `fsevents` module at all. While this does trigger a semver violation because webpack 4 depends on chokidar 2, the API is apparently similar enough that all the tests pass. It does however give rise to a warning in the console upon installation of depedencies via a `yarn`. This resolution can be removed once an upgrade is made to webpack 5 or to a different depedency bundler like [parcel][3] or [rollup][4]. Learning -------- * [Selective dependency resolutions ][5] [1]: webpack/webpack#10037 [2]: fsevents/fsevents#314 [3]: http://parceljs.org [4]: https://rollupjs.org [5]: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/
The fix turns out to be bumping `webpack` from `4.43` to `4.44` in `packages/web-components`. Prior to this, I'd experience sporadic errors when running `yarn test` like the ones documented in this `karma` issue: [karma-runner/karma#3511](karma-runner/karma#3511). It turns out, that the problem is not with `karma` but rather with `webpack` as documented in [webpack/webpack#10037](webpack/webpack#10037). As per the closing comment in that issue, ensure we use `watchpack` version `^1.7.2` (a transitive dep of `webpack`) is enough to ensure this sporadic error goes away, and to bump `watchpack` we need to bump `webpack` by one minor version.
The fix turns out to be bumping `webpack` from `4.43` to `4.44` in `packages/web-components`. Prior to this, I'd experience sporadic errors when running `yarn test` like the ones documented in this `karma` issue: [karma-runner/karma#3511](karma-runner/karma#3511). It turns out, that the problem is not with `karma` but rather with `webpack` as documented in [webpack/webpack#10037](webpack/webpack#10037). As per the closing comment in that issue, ensure we use `watchpack` version `^1.7.2` (a transitive dep of `webpack`) is enough to ensure this sporadic error goes away, and to bump `watchpack` we need to bump `webpack` by one minor version.
The fix turns out to be bumping `webpack` from `4.43` to `4.44` in `packages/web-components`. Prior to this, I'd experience sporadic errors when running `yarn test` like the ones documented in this `karma` issue: [karma-runner/karma#3511](karma-runner/karma#3511). It turns out, that the problem is not with `karma` but rather with `webpack` as documented in [webpack/webpack#10037](webpack/webpack#10037). As per the closing comment in that issue, ensure we use `watchpack` version `^1.7.2` (a transitive dep of `webpack`) is enough to ensure this sporadic error goes away, and to bump `watchpack` we need to bump `webpack` by one minor version.
- There are two issues. One is: webpack/webpack#10037. - Likely related alongside this, is the socket and frontend not connecting with one another. Was able to drill down to figure out the frontend is the issue. fsevents dependency and two versions on Mac seems to be messing things up - Above seemed to point to needing to update to webpack 5 in order to use this on Macs. - Updated most dependencies. Not socket.io-client (4.5.3), nanoid (4.0.0), winston (3.8.2) yet. - React updated to 18.2 from 17. react-scripts from 4 to 5 - react-app-rewired installed for config-overrides to try to fix new bugs coming up. Installed os-browserify, browserify-zlib for this. - I think I pointlessly installed react-router. Seems like that wasn’t around before. Downgraded from react-router and react-router-dom 6 to 5. Initially react-router-dom was at 5.3. Likely go back to that next commit and remove react-router.
Bug report
When closing a watching compiler programmatically, the node process crashes.
What is the current behavior?
Getting the following crash in several repositories on our Mac CIs:
If the current behavior is a bug, please provide the steps to reproduce.
yarna.js:node a.jsWhat is the expected behavior?
(for the above code) watch -> wait for 1 sec -> close watcher -> rewatch and repeat process.
Other relevant information:
webpack version: 4.41.2
Node.js version: 13.2.0
Operating System: Mac 10.12.6
@sokra maybe this is because
watchpackis using oldchokidarwith outdatedfsevents? :/The text was updated successfully, but these errors were encountered: