Never ending "Waiting for framework" in 19.0.3

[Simbul]

Describe the bug

Since upgrading to 19.0.3, netlify dev is constantly showing the following message, with a spinner on the left:

⠦ Waiting for framework port 5173. This can be configured using the 'targetPort' property in the netlify.toml

Running the same command with 19.0.2 does not result in the same behaviour. In fact, the wait seems to be over pretty quickly:

✔ Waiting for framework port 5173. This can be configured using the 'targetPort' property in the netlify.toml

This is printed out before the message saying Server now ready on http://localhost:8888

Steps to reproduce

1. Start in the root of my repo (apologies, this is a private project)
2. Upgrade netlify-cli to 19.0.3
3. Run netlify dev
4. Everything seems to be working fine, but the CLI keeps "waiting for framework port 5173"

Configuration

[build]
command = "react-router build"
publish = "build/client"

[dev]
command = "react-router dev"

Environment

  System:
    OS: macOS 15.3.2
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 3.13 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 23.10.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.9.2 - /usr/local/bin/npm
  npmGlobalPackages:
    netlify-cli: 19.0.3

[ffaubert]

I'm having the same issue, had to downgrade back to 19.0.2

[ndhoule]

@Simbul @ffaubert I'm unable to reproduce this myself, but I can definitely investigate more if either of you can put together a minimal reproducible example! Doesn't need to be your full app, just enough to consistently trigger this behavior.

[ffaubert]

@ndhoule It seems to be an issue with netlify and vite. I put together a very simplistic test case at https://github.com/ffaubert/netlify-cli-test.

To reproduce after npm install, run netlify dev and then make a change to public/index.html and you'll see
⠋ Waiting for framework port 5173. This can be configured using the 'targetPort' property in the netlify.toml
forever.

Also new in v19.0.3 at startup I see:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(Use node --trace-warnings ... to show where the warning was created)
(node:61086) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

That was not there in 19.0.2

Thank you for investigating this!

[ndhoule]

@ffaubert Thanks for the repro! I'm seeing the EventEmitter warning, but I'm not able to reproduce the behavior. I'm on Linux, which might explain the difference; I'll pair up with a coworker who runs macOS to see if this is a platform-specific issue.

I'll keep you both posted--thanks for your patience in the meantime.

[serhalp]

@Simbul @ffaubert I think I may have a fix for this in #7135. Could you give it a try and let me know if it's fixed?

npm i -g [email protected]

(Note that this won't fix the MaxListenersExceededWarning, just the hanging netlify dev)

[Simbul]

Thank you @serhalp. Unfortunately, I'm still seeing the same behaviour on the version you specified

$ netlify version
netlify-cli/19.0.3-pre.9266a2d darwin-x64 node-v23.10.0

When using netlify dev, the message ⠹ Waiting for framework port 5173. This can be configured using the 'targetPort' property in the netlify.toml is always printed as the last line of the server output (i.e. the same behaviour from my initial post).

[Simbul]

To add more data: I'm still seeing the same behaviour on netlify-cli/19.1.5 darwin-x64 node-v23.10.0.

[Simbul]

Also, still there in 20.0.0.

[Florian-Mt]

It looks like if (spinner.isSpinning) (here: /src/utils/shell.ts#L64) is missing call parentheses, as isSpinning is a function (see : usmanyunusov/nanospinner:/src/index.ts#L183).
So the condition is always true. I bet that it was not intentional.
It seems better after adding parens.

[serhalp]

Thanks for spotting that @Florian-Mt — that's an embarrassing one!

I'll prepare a fix. For some reason I can actually finally repro this issue now, so I'll be able to confirm the fix.

[serhalp]

Hey folks, this should be finally fixed in 21.0.0. Thanks for bearing with us!