Workaround for CLI-driven init tasks (when using vite)?

[kbzowski]

I'm using Nitro v3 alpha as a Vite plugin (nitro/vite) and I've run into an issue with tasks CLI.
When Nitro runs as a Vite plugin, nitro task list and nitro task run fail with:
Missing info file: node_modules/.nitro/nitro.dev.json (is dev server running?)
This makes sense - in Vite plugin mode, Nitro doesn't spin up its own dev server, so the .nitro/nitro.json file that the CLI relies on never gets created.
I know I can hit /_nitro/tasks and /_nitro/tasks/:name endpoints directly via HTTP as a workaround in dev, but my use case requires running tasks from the CLI - specifically for system initialization/installation steps that need to happen before the app is fully up and usable.

Am I missing something in the setup? Is there a way to make the CLI work in Vite plugin mode, or a recommended pattern for this kind of init workflow?
Any pointers appreciated. Thanks!

[everton-dgn]

Yeah, in Vite plugin mode Nitro doesn't own the dev server, so the info file the CLI looks for never gets written. You already found the two real paths forward.

1. Hit the HTTP endpoints directly while the dev server is running:

curl http://localhost:5173/_nitro/tasks
curl -X POST http://localhost:5173/_nitro/tasks/db:seed

Tiny wrapper if you want a CLI shape:

// scripts/run-task.ts
const [task] = Bun.argv.slice(2)
const res = await fetch(`http://localhost:5173/_nitro/tasks/${task}`, { method: "POST" })
console.log(await res.json())

2. Pull init logic out of the task and into a plain script that can run before the server comes up:

// server/utils/db.ts
export async function runMigrations() { /* shared logic */ }

// scripts/init.ts
import { runMigrations } from "../server/utils/db"
await runMigrations()

Option 2 is the one I'd reach for when the task has to run before the server is up, since option 1 obviously needs the dev server running. There's currently no way to make the CLI work in Vite plugin mode without the dev info file. Filing an issue to have the CLI fall back to HTTP discovery would be reasonable.