'Npm start' fails on react-scripts-start initial attempt

ISSUE

npm start is failing to work with create-react-app after initial ‘create-react-app my-app’ install. Complete output log is below.

I get similar output when trying to run another create-react-app that I copied in from another machine.

I initially tried this with node v8.9.4 and npm v5.6.0 and got the errors below.

I then installed a different node version using ‘npm install -g npm@4’, removed node_modules, cleared the cache, and ran another ‘npm install’.

I then tried npm start with node v8.9.4 and npm v4.6.1, and got the same errors.

I searched for ‘Exit status’ and ‘react-scripts start’ in the documentation but didn’t come up with anything.

running ‘npm ls react-scripts’ yields ’ 'react-scripts@1.0.17 ’

I’m using bash shell on Windows 10, and the latest version of Google Chrome.

INITIAL OUTPUT:

capndavet@PC102:/mnt/c/Users/dthompson/Documents/protest-app$ npm start
> protest-app@0.1.0 start /mnt/c/Users/dthompson/Documents/protest-app
> react-scripts start
os.js:126
  const interfaceAddresses = getInterfaceAddresses();                                                                                                ^     
Error: EINVAL: invalid argument, uv_interface_addresses
  at Object.networkInterfaces (os.js:126:30)
  at Function.address.interface (/mnt/c/Users/dthompson/Documents/protest-app/node_modules/address/lib/address.js:58:23)  
  at Function.address.ip (/mnt/c/Users/dthompson/Documents/protest-app/node_modules/address/lib/address.js:97:31)
  at err (/mnt/c/Users/dthompson/Documents/protest-app/node_modules/detect-port-alt/lib/detect-port.js:75:30)
  at Server.server.listen (/mnt/c/Users/dthompson/Documents/protest-app/node_modules/detect-port-alt/lib/detect-port.js:100:12)
  at Object.onceWrapper (events.js:313:30)
  at emitNone (events.js:106:13)
  at Server.emit (events.js:208:7)
  at emitListeningNT (net.js:1378:10)
  at _combinedTickCallback (internal/process/next_tick.js:135:11)
  at process._tickCallback (internal/process/next_tick.js:180:9)
npm ERR! code ELIFECYCLE 
npm ERR! errno 1
npm ERR! protest-app@0.1.0 start: `react-scripts start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the protest-app@0.1.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.                                                                                                                                              npm ERR! A complete log of this run can be found in:
npm ERR!     /home/capndavet/.npm/_logs/2018-01-04T16_27_50_082Z-debug.log `

DEBUG LOG

capndavet@PC102:/mnt/c/Users/dthompson/Documents$ cat /home/capndavet/.npm/_logs/2018-01-04T16_39_14_234Z-debug.log
 0 info it worked if it ends with ok
1 verbose cli [ '/home/capndavet/.nvm/versions/node/v8.9.4/bin/node',
1 verbose cli   '/home/capndavet/.nvm/versions/node/v8.9.4/bin/npm', 
1 verbose cli   'start' ]
2 info using npm@5.6.0
3 info using node@v8.9.4
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle protest-app@0.1.0~prestart: protest-app@0.1.0
6 info lifecycle protest-app@0.1.0~start: protest-app@0.1.0
7 verbose lifecycle protest-app@0.1.0~start: unsafe-perm in lifecycle true
8 verbose lifecycle protest-app@0.1.0~start: PATH: /home/capndavet/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/mnt/c/Users/dthompson/Documents/protest-app/node_modules/.bin:/home/capndavet/.nvm/versions/node/v8.9.4/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
9 verbose lifecycle protest-app@0.1.0~start: CWD: /mnt/c/Users/dthompson/Documents/protest-app                          10 silly lifecycle protest-app@0.1.0~start: Args: [ '-c', 'react-scripts start' ]
11 silly lifecycle protest-app@0.1.0~start: Returned: code: 1  signal: null
12 info lifecycle protest-app@0.1.0~start: Failed to exec start script
13 verbose stack Error: protest-app@0.1.0 start: `react-scripts start`
13 verbose stack Exit status 1
13 verbose stack at EventEmitter.<anonymous> (/home/capndavet/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:285:16)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at EventEmitter.emit (events.js:214:7)
13 verbose stack     at ChildProcess.<anonymous> (/home/capndavet/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at ChildProcess.emit (events.js:214:7)
13 verbose stack     at maybeClose (internal/child_process.js:925:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)                           14 verbose pkgid protest-app@0.1.0
15 verbose cwd /mnt/c/Users/dthompson/Documents/protest-app                                                             16 verbose Linux 3.4.0+
17 verbose argv "/home/capndavet/.nvm/versions/node/v8.9.4/bin/node" "/home/capndavet/.nvm/versions/node/v8.9.4/bin/npm" "start"                                                                                                                18 verbose node v8.9.4
19 verbose npm  v5.6.0
20 error code ELIFECYCLE
21 error errno 1
22 error protest-app@0.1.0 start: `react-scripts start`
22 error Exit status 1
23 error Failed at the protest-app@0.1.0 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.                      24 verbose exit [ 1, true ]                                          

[gaearon]

For the original issue, this looks related: https://github.com/Microsoft/WSL/issues/468 Apparently fixed in this update: https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/.

I don’t know why a similar problem exists on Linux (per https://github.com/facebookincubator/create-react-app/issues/3690#issuecomment-356434128), but per the same report removing node_modules and doing an npm install seems to fix it.

I don’t think there’s anything that needs to be done on our side.

[Timer]

It looks like a Node bug on this specific users configuration, but we should probably make our fork of detect-port swallow it & emit a warning then return true (since an attempt of binding is better than nothing).