API Server is always listening, even if disabled

[mvantellingen]

Describe the bug

For a while now I get a popup in MacOS that node wants to listen to incoming network connections. Diving into this now with NODE_DEBUG=net it seems vitest is opening a server:

NET 39096: setupListenHandle null 24678 4 0 undefined
NET 39096: setupListenHandle: create a handle
NET 39096: bind to ::

Setting api: false in the config doesn't work, I can modify these values however. When setting the following in my vitest config:

api: {
  port: 36321,
  host: "127.0.0.1",
}

And the NODE_DEBUG=net output is:

NET 39562: setupListenHandle 127.0.0.1 36321 4 false undefined
NET 39562: setupListenHandle: create a handle
NET 39562: bind to 127.0.0.1

 RUN  v1.4.0 /Users/mvantellingen/foobar
      API started at http://127.0.0.1:36321/

So explicitly setting the API config modifies the listen port, and actually shows that the API is starting.

Reproduction

Run vitest using NODE_DEBUG=net and look for the output

System Info

System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 1.13 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.7.1 - /opt/homebrew/bin/node
    Yarn: 1.22.22 - /opt/homebrew/bin/yarn
    npm: 10.5.0 - /opt/homebrew/bin/npm
    pnpm: 8.15.5 - /opt/homebrew/bin/pnpm
    bun: 1.1.0 - /opt/homebrew/bin/bun
  Browsers:
    Chrome: xx
    Edge: xx
    Safari: xx
  npmPackages:
    @vitest/coverage-v8: 1.4.0 => 1.4.0
    vitest: 1.4.0 => 1.4.0

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sheremet-va]

I don't see your logs with setupListenHandle in https://github.com/vitest-dev/vitest/tree/main/examples/basic

I do see these:

NET 60059: _read - n 16384 isConnecting? false hasHandle? true
NET 60059: Socket._handle.readStart
NET 60059: _read - n 16384 isConnecting? false hasHandle? true
NET 60059: _read - n 16384 isConnecting? false hasHandle? true
NET 60059: _read - n 16384 isConnecting? false hasHandle? true
NET 60059: _read - n 16384 isConnecting? false hasHandle? true
NET 60059: _read - n 16384 isConnecting? false hasHandle? true

They are coming from esbuild's build function it looks like. This is not an open server from what I can tell.

[github-actions]

Hello @mvantellingen. Please provide a minimal reproduction using a GitHub repository or StackBlitz (you can also use examples). Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[mvantellingen]

I added an example at https://github.com/mvantellingen/vitest-reproduction

I did need to make some changes in the vitest config to trigger the issue, as we import the defineConfig() from import { defineConfig } from 'vitest/config'

[sheremet-va]

Can confirm that it happens because of this: vitejs/vite#14328