agent-friendly dev/preview server mode

[KTrain5169]

Description

Writing code with agents is a great experience with Vite... right up until the agent wants to use the dev server. Because of how a dev server works (long-running execution, pretty-looking logs printed as they come in, etc), agents have trouble working with dev servers, either spawning dev servers without shutting them down first which consequently slows down the user's machine and stealing resources or the agent becomes completely frozen until the user manually intervenes and shuts down the command line for them. Not exactly great.

Suggested solution

The Astro team have also seen this behaviour with their triaging AI agent, as they note in the Astro 7 release post, talking about their new background dev server. Their new background dev server ensures the agent doesn't trip up on dev servers by being more agent-friendly:

• command line only blocks until the dev server is ready
• the command line prints simplified dev commands the agent can use that also follow this philosophy
• the existing instance is recorded on disk and returned to the agent when they try to start another dev server

I think something similar could work for Vite (and be adoptable for tools that build on top like Vitest watch mode).

If desired, this philosophy can also be extended down to the Rolldown layer and replicated into tsdown, although that will be its own separate issue on their respective repositories.

Alternative

There are probably other agent-friendly dev server setups that could work here, one that I came up with is using simply not recording the lockfile and somehow checking for an existing PID running Vite. This has some advantages and disadvantages over the solution mentioned above, but it is a solution that may be worth considering.

Alongside this, there can potentially also be a slightly tweaked implementation for Vite, compared to Astro. For example, the agent might be able to curl a special endpoint to trigger commands instead of using the CLI, or maybe Vite outputs plaintext/markdown logs instead of JSON.

Additional context

Even if the Vite dev server doesn't become more agent-friendly, the lockfile feature alone could be helpful in case a human (like me late at night) forgets they already have a dev server up and transforming. It would also be friendly for scripts and other stuff to build around. Additionally, I think the preview server and dev server can coexist independently, and maybe a warning could pop up if, say, a dev server is already running but the user is spawning a preview server. The rational is that the preview server is serving pre-compiled output that may be what the user is wanting to reference when modifying the code, which would then be displayed by the dev server.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sapphi-red]

My opinion on this is same with withastro/roadmap#1308 (comment).

For example, with Claude Code if you kill the process then the child process of astro is also killed. I would guess that with astro dev --background the process will not be killed in the case of the parent being killed. It probably would also not be killed if you did /exit, but rather you'd need to tell it to kill the process.

I think this is an interesting point.

---

@TheAlexLichter suggested a lock file and using that to detect duplicate dev servers. I think that can work better for those agents. I think it's also useful for humans as well.

The flow would be like:

• when the command starts, write .vite/lock/${hash}.json which contains the config file path, mode, command (dev, preview, build). The hash is calculated from the content of the file itself.
• when the command ends (SIGINT, q in CLI), remove .vite/lock/${hash}.json. This might be tricky to ensure.

[KTrain5169]

The flow would be like:

• when the command starts, write .vite/lock/${hash}.json which contains the config file path, mode, command (dev, preview, build). The hash is calculated from the content of the file itself.

I would also suggest including the PID and host:port URI as well.

• when the command ends (SIGINT, q in CLI), remove .vite/lock/${hash}.json. This might be tricky to ensure.

If the PID is included then you could check for the PID and see if it's there, if the PID does exist but the process doesn't point to it being a Vite dev server, then assume that Vite was improperly shut down and just wipe it. I think that's probably the cleanest to go about it, though there may be other methods too.