Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jest-dev-server port detection is not working #460

Closed
lfdebrux opened this issue Dec 8, 2021 · 5 comments · Fixed by #518
Closed

jest-dev-server port detection is not working #460

lfdebrux opened this issue Dec 8, 2021 · 5 comments · Fixed by #518

Comments

@lfdebrux
Copy link

lfdebrux commented Dec 8, 2021

🐛 Bug Report

I think (unless I've misconfigured something) that with the latest version of jest if you have a process running already on the server port then the port detection won't happen, and tests and jest-dev-server will try to continue anyway.

To Reproduce

Steps to reproduce the behavior:

  1. Start a HTTP server listening on port 3000, for instance with npx http-server -p 3000
  2. With the test project (or any project using jest 27.4.3 and jest-dev-server) run npx jest
  3. An error from the server command will be output to the terminal with an EADDRINUSE error

Expected behavior

In the past jest-dev-server has prompted the user whether they want to kill the existing process.

Link to repl or repo (highly encouraged)

Repo with minimal example:

https://github.com/lfdebrux/test-jest-dev-server

Run npx envinfo --system --binaries --npmPackages expect-puppeteer,jest-dev-server,jest-environment-puppeteer,jest-puppeteer,spawnd --markdown --clipboard

Paste the results here:

*** Clipboard option removed - use clipboardy or clipboard-cli directly ***


## System:
 - OS: macOS 11.6.1
 - CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
 - Memory: 86.04 MB / 16.00 GB
 - Shell: 5.1.8 - /usr/local/bin/bash
## Binaries:
 - Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
 - npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
## npmPackages:
 - jest-dev-server: ^6.0.2 => 6.0.2 
@lfdebrux
Copy link
Author

lfdebrux commented Dec 8, 2021

I've tested the minimal example with jest@27.0.0 and jest@26.6.3 and it fails then too :(

@lfdebrux lfdebrux changed the title jest-dev-server is trying to run server command even if port is already taken jest-dev-server port detection is not working Dec 8, 2021
@lfdebrux
Copy link
Author

lfdebrux commented Dec 8, 2021

I also can't get the expected behaviour with jest-dev-server@6.0.0 or jest-dev-server@5.0.3 (with jest@27.4.3). Can't get the expected behaviour with jest-dev-server@5.0.3 and jest@26 either, which I'm sure I've seen working before. Maybe it's something in a sub-dependency somewhere?

@UziTech
Copy link
Contributor

UziTech commented Dec 8, 2021

The issue with jest@26 might be related to #421

@lfdebrux
Copy link
Author

lfdebrux commented Dec 9, 2021

I've made a more minimal example that doesn't include jest at all: https://github.com/lfdebrux/test-jest-dev-server/tree/no-jest

The really strange thing is that on my machine the log message dev server is running is printed before the error message from the dev server:

# in one terminal
% python -m http.server 3000

# in another terminal
% node test.js 
dev server is running
node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE: address already in use 0.0.0.0:3000
    at Server.setupListenHandle [as _listen2] (node:net:1334:16)
    at listenInCluster (node:net:1382:12)
    at doListen (node:net:1520:7)
    at processTicksAndRejections (node:internal/process/task_queues:84:21)
Emitted 'error' event on Server instance at:
    at emitErrorNT (node:net:1361:8)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  code: 'EADDRINUSE',
  errno: -48,
  syscall: 'listen',
  address: '0.0.0.0',
  port: 3000
}

I'm not sure what this means. It's possible that its a macOS thing, I haven't tested on other systems.

@josephwynn-sc
Copy link

Just chiming in to say that I have this issue on my Macbook but not my other laptop running Linux, which might confirm the previous commenter's suspicion that this is a macOS thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants