random crashes under npm run dev

When I’m under npm run dev, I got random crashes from time to time. Whenever it happens, I’ll have to kill the job and start it all over again, which normally takes around 45-60 seconds. The crash seems to be pretty random. I could be changing some files and be OK, but a few min later, the same change could cause the crash. The rebuilding is also quite slow as well, around 3-5 seconds each time.

Just FYI, here is the screen output. It’s not consistent though. Sometimes the message is slightly different. I’m running node js on windows 10. (node.js v4.3.1, npm v2.14.12). It happens on ubuntu as well. Anyone else got this problem?

[1] [piping] File src\config.js has changed, reloading.
[1] [piping] can't execute file: C:\code\repos\adxfront\bin\server.js
[1] [piping] error given was: TypeError: res.writeHead is not a function
[1]     at ProxyServer.<anonymous> (server.js:55:9)
[1]     at ProxyServer.emit (C:\code\repos\adxfront\node_modules\http-proxy\node_modules\eventemitter3\index.js:117:27)
[1]     at Socket.onOutgoingError (C:\code\repos\adxfront\node_modules\http-proxy\lib\http-proxy\passes\ws-incoming.js:153:16)
[1]     at emitOne (events.js:82:20)
[1]     at Socket.emit (events.js:169:7)
[1]     at emitErrorNT (net.js:1255:8)
[1]     at nextTickCallbackWith2Args (node.js:437:9)
[1]     at process._tickCallback (node.js:351:17)
[1] [piping] further repeats of this error will be suppressed...
[1] events.js:141
[1]       throw er; // Unhandled 'error' event
[1]       ^
[1]
[1] Error: write EPIPE
[1]     at exports._errnoException (util.js:870:11)
[1]     at ChildProcess.target._send (internal/child_process.js:606:18)
[1]     at ChildProcess.target.send (internal/child_process.js:507:12)
[1]     at sendHelper (cluster.js:717:8)
[1]     at send (cluster.js:512:5)
[1]     at suicide (cluster.js:444:5)
[1]     at Worker.onmessage (cluster.js:431:7)
[1]     at ChildProcess.<anonymous> (cluster.js:731:8)
[1]     at emitTwo (events.js:92:20)
[1]     at ChildProcess.emit (events.js:172:7)
[0] webpack building...
[1]
[1] npm
[1]  ERR! Windows_NT 10.0.10586
[1] npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "start-dev"
[1] npm ERR! node v4.3.1
[1] npm ERR! npm  v2.14.12
[1] npm ERR! code ELIFECYCLE
[1] npm ERR! react-redux-universal-hot-example@0.9.0 start-dev: `better-npm-run start-dev`
[1] npm ERR! Exit status 1
[1] npm ERR!
[1] npm ERR! Failed at the react-redux-universal-hot-example@0.9.0 start-dev script 'better-npm-run start-dev'.
[1] npm ERR! This is most likely a problem with the react-redux-universal-hot-example package,
[1] npm ERR! not with npm itself.
[1] npm ERR! Tell the author that this fails on your system:
[1] npm ERR!     better-npm-run start-dev
[1] npm ERR! You can get their info via:
[1] npm ERR!     npm owner ls react-redux-universal-hot-example
[1] npm ERR! There is likely additional logging output above.
[1]
[1] npm ERR! Please include the following file with any support request:
[1] npm ERR!     C:\code\repos\adxfront\npm-debug.log
[1] npm run start-dev exited with code 1
--> Sending SIGTERM to other processes..
[0] webpack built 051a8503341325da9b9f in 5721ms
[2] ----
[2] ==> �  API is running on port 3030
[2] ==> �  Send requests to http://localhost:3030

[realbugger]

@jjpatel361 you’re right. The problem is with piping. I’ve updated my piping package from 0.3.2 to the latest 1.0.0-rc.1 this morning, and haven’t had a single crash for the last 7 hours or so, which is quite a smooth sailing considering that normally it crashes once every 30 min or so.

Looks like it also solved the ‘rebuild but dev-server won’t restart’ issue (#1137). The dev-server restarts reliably every time after rebuild. However, for some reason, not every time it shows follow message, though.

[1] ----
[1] ==> ✅  App is running, talking to API server on 3030.
[1] ==> �  Open http://localhost:3000 in a browser to view the app.

I’m not sure if updating piping package completely solved the problem. But so far so good. Closing the issue.

[PedramMarandi]

I have the same issue here, I’ve also tested piping@1.0.0-rc.1