Background dev server for AI coding agents#16610
Conversation
🦋 Changeset detectedLatest commit: 105a113 The changes in this PR will be included in the next version bump. This PR includes changesets to release 401 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Merging this PR will degrade performance by 84.2%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | Build: hybrid site (static + server) |
1.7 s | 9.9 s | -82.68% |
| ❌ | Simulation | Build: full static site |
784.3 ms | 4,928.3 ms | -84.09% |
| ❌ | Simulation | Build: full server site |
1.6 s | 10 s | -84.2% |
Comparing background-dev (06744ad) with next (e322c24)1
Footnotes
commit: |
| "@clack/prompts": "^1.1.0", | ||
| "@oslojs/encoding": "^1.1.0", | ||
| "@rollup/pluginutils": "^5.3.0", | ||
| "am-i-vibing": "^0.1.1", |
There was a problem hiding this comment.
I suggest upgrading to 0.2.0: it can use env vars to detect most tools instead of needing process ancestry, so should be a lot quicker on Windows.
| ` URL: ${existingServer.url}`, | ||
| ` PID: ${existingServer.pid}`, | ||
| '', | ||
| `Run \`kill ${existingServer.pid}\` to stop it, or use \`astro dev --force\` to replace it.`, |
There was a problem hiding this comment.
Should this say to run astro dev --experimental-stop rather than kill?
There was a problem hiding this comment.
Yeah, you intended these to be just astro dev stop, not flags right? I think I'm going to get rid of the experimental flags and just submit this directly to next.
The reason is that we can't really effectively do an experimental here since this is only useful if agents get it by default, so better to do it directly in v7.
There was a problem hiding this comment.
This now explains to use astro stop instead.
| ], | ||
| ['--experimental-stop', 'Stop a running background dev server.'], | ||
| ['--experimental-status', 'Check if a dev server is running.'], | ||
| ['--experimental-logs', 'View logs from a background dev server.'], |
There was a problem hiding this comment.
--experimental-restart is a useful one too, though it would require storing the flags to re-send.
There was a problem hiding this comment.
I don't think we need this, we have --force which overrides the lockfile, so let the agent remember what the flags are.
| } | ||
|
|
||
| const content = readFileSync(logFilePath, 'utf-8'); | ||
| process.stdout.write(content); |
There was a problem hiding this comment.
A --follow flag is a nice addition for humans.
| const deadline = Date.now() + 5000; | ||
| while (Date.now() < deadline) { | ||
| if (!isProcessAlive(existing.pid)) break; | ||
| await new Promise((r) => setTimeout(r, 100)); | ||
| } |
There was a problem hiding this comment.
Might be worth doing a SIGKILL if it's still alive after the timeout
|
|
||
| function isRunByAgent(): boolean { | ||
| try { | ||
| return isAgent(); |
There was a problem hiding this comment.
This info (and the specific agent) might be a useful addition to telemetry
There was a problem hiding this comment.
Very easy! Good library we have 😉 06744ad
…to 0.3.0 - Replace --experimental-background/stop/status/logs flags with positional subcommands: astro dev background, astro dev stop, astro dev status, astro dev logs - Update error/info messages to reference new subcommand form - Upgrade am-i-vibing from ^0.1.1 to ^0.3.0 for faster env-var-based agent detection and broader tool coverage
Streams new log output as it's written, similar to tail -f. Automatically exits when the server process dies.
If a dev server process doesn't exit within 5s of SIGTERM, escalate to SIGKILL to guarantee it's dead before proceeding.
Calls detectAgenticEnvironment() from am-i-vibing in eventCliSession() so all CLI commands (dev, build, preview, sync, add) report agent id, name, and type when run by an AI coding agent.
e18e dependency analysisNo dependency warnings found. |
# Conflicts: # pnpm-lock.yaml
| if (flags.config) args.push('--config', String(flags.config)); | ||
| if (flags.root) args.push('--root', String(flags.root)); | ||
| if (flags.allowedHosts) args.push('--allowed-hosts', String(flags.allowedHosts)); | ||
| if (flags.experimentalJson) args.push('--experimental-json'); |
There was a problem hiding this comment.
Reminder that I will rename this to json, so it's best to rebase this PR after I merge my custom logger PR. Better to track it in linear so we don't stomp on each other
|
I just read the RFC, and I think the log rotation is missing. Or am I hallucinating? 😆 |
|
Log rotation has been removed from the RFC. The log file is truncated on each new background server start, so unbounded growth only happens during a single long-running session — which is unlikely to hit any meaningful size for a dev server. Log rotation is typically handled externally (logrotate, etc.) and not by the process itself. |
|
Added docs PR here: withastro/docs#13949 |
| export function resolveRootURL(root?: string): URL { | ||
| const rootPath = typeof root === 'string' ? resolve(root) : process.cwd(); | ||
| return pathToFileURL(rootPath + '/'); | ||
| } |
There was a problem hiding this comment.
This hasn't been addressed. We already have this function
astro/packages/astro/src/core/config/config.ts
Lines 20 to 25 in f387eba
It doesn't have the same return signature, but it does the same thing. We should use just one
ArmandPhilippot
left a comment
There was a problem hiding this comment.
A nit, and same concern as Ema regarding telemetry. Otherwise, LGTM docs-wise!
| /** Whether the CLI session was run by an AI coding agent. */ | ||
| isAgentic?: boolean; | ||
| /** ID of the detected agent, e.g. "cursor-agent", "claude-code". */ | ||
| agentId?: string; | ||
| /** Display name of the detected agent, e.g. "Cursor Agent", "Claude Code". */ | ||
| agentName?: string; | ||
| /** Type of agentic environment: "agent", "interactive", or "hybrid". */ | ||
| agentType?: string; |
There was a problem hiding this comment.
I think I agree with Ema that "general machine information" might not cover "AI agents" and it might be better to add it to the list.
|
@ematipico @ArmandPhilippot about telemetry, my pushback here is that i don't want us to get to a place where every change to telemetry requires updating the website. Not even because of the maintenance cost, but rather because if we over-disclose then we are in a situation where if we forget to update the website we get accused of hiding what we're doing. So I'll open a PR on astro.build that aims to make the language general enough to cover this but without being specific. Just giving the context for that change here. |
Co-authored-by: Armand Philippot <[email protected]>
|
I completely understand that and I know why we want to have a generic language to avoid too many updates. Be mindful though, because we might fall into a place where not disclosing the information could have negative effects on the project (users not knowing, etc.). |
Changes
Implements RFC:
astro dev --background. When an AI coding agent is detected (viaam-i-vibing),astro devautomatically starts the dev server as a detached background process so it doesn't block the agent's terminal.astro dev --backgroundflag andastro dev stop,astro dev status, andastro dev logssubcommands for managing background dev servers.astro/dev.json) on server start to prevent duplicate servers and enable the subcommands to find the running instance/_astro/statushealth endpoint for programmatic readiness checksastro dev logs --followstreams new log output as it's written, exits when the server diesastro dev stopandastro dev --background --forceescalate to SIGKILL if the process doesn't exit within 5 seconds of SIGTERMASTRO_CLI_SESSION_STARTEDtelemetry events for all CLI commandsNo action required from users. If no agent is detected,
astro devbehaves exactly as before.Testing
test/units/dev/lockfile.test.ts,test/units/dev/dev-output.test.ts)Docs
astro dev --backgroundto CLI reference docs#13949