`vp run`: scripts get a non-blocking stdin (EAGAIN) when `run` tasks in vite.config.ts use constants
Mantenedores costumam responder em até 1 dia
@wan9chi já está trabalhando nisso.
Desde 22/10/2026.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 55/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- bun, node.js, rust, typescript
Direção de pesquisa
Start by tracing vp run startup and how it loads vite.config.ts and starts the task process; the report points to ensureBlockingStdio() in dist/bin.js as related context. Reproduce with the supplied project, comparing the constant reference and string literal configurations, then inspect where stdin becomes non-blocking. Done means both configurations keep the probe waiting for input and the interactive update prompt accepts input.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Describe the bug
On macOS, interactive prompts started with vp run exit without waiting for input when a task in the run block of vite.config.ts references a constant.
With Bun as the package manager, vp run up, where up is vp update --interactive --latest, prints the package list and exits with Selected 0 packages to update before any key is pressed. Running vp update --interactive --latest directly, or bun run up, waits for input.
A blocking read of stdin shows the cause: the script started by vp run gets a stdin in non-blocking mode. probe.mjs calls readSync(0), and under vp run that call fails right away with EAGAIN. I have not identified what sets O_NONBLOCK.
Neither vp run probe nor vp run up invokes the hello task defined in the run block. Changing its command from a constant reference to the same string literal changes whether these scripts wait for input:
vite.config.ts |
vp run probe |
|---|---|
no run block |
waits for input, then prints stdin is blocking |
run: { tasks: { hello: { command: 'echo hello' } } } |
waits for input, then prints stdin is blocking |
const command = 'echo hello' and run: { tasks: { hello: { command } } } |
prints stdin is non-blocking: EAGAIN immediately, without waiting for input |
After vp exits, stdin returns to blocking mode.
I found this through vp run deps:update in a project whose run tasks spread shared constants into cache.input. There it happened with vite-plus 1.2.0 and 1.3.0. I tested the reproduction below with 1.3.0.
Possibly related: #2173 added ensureBlockingStdio(), which vite-plus 1.3.0 calls at startup in dist/bin.js. This case still happens on 1.3.0. I have not established whether the two share a cause.
Reproduction
https://github.com/everton-dgn/vp-run-stdin-nonblock
Steps to reproduce
Open a terminal in the reproduction directory. Run the commands below with stdin connected to the terminal, without piping or redirecting input.
bun installvp run probe- Expected: it prints
Waiting for one byte on stdin. Press Enter.and waits. After Enter, it printsstdin is blocking. - Actual: it prints
stdin is non-blocking: EAGAINwithout waiting.
- Expected: it prints
vp run up- Expected: the package selection list waits for input.
- Actual: the list is drawn and then replaced right away by
Selected 0 packages to updateandNo packages selected for update.
- Controls. Run
node probe.mjsand press Enter; it printsstdin is blocking. Then runvp update --interactive --latestandbun run upseparately. Each one waits at the package selection list. Cancel each list with Ctrl+C, without updating any package. - Run
cp vite.config.literal.ts vite.config.ts. This writes the same task with the command as a string literal. Repeat steps 2 and 3: both commands now wait for input.
Besides bun.lock and a README with these steps, the repository has these files:
package.json
{
"name": "vp-run-stdin-nonblock",
"private": true,
"type": "module",
"packageManager": "[email protected]",
"scripts": {
"probe": "node probe.mjs",
"up": "vp update --interactive --latest"
},
"dependencies": {
"is-number": "6.0.0"
},
"devDependencies": {
"vite-plus": "1.3.0"
}
}
probe.mjs
import { readSync } from 'node:fs'
console.log('Waiting for one byte on stdin. Press Enter.')
try {
readSync(0, Buffer.alloc(1))
console.log('stdin is blocking')
} catch (error) {
console.log(`stdin is non-blocking: ${error.code}`)
}
vite.config.ts, the version that fails:
import { defineConfig } from 'vite-plus'
const command = 'echo hello'
export default defineConfig({
run: {
tasks: {
hello: { command }
}
}
})
vite.config.literal.ts, the version that works when copied over vite.config.ts:
import { defineConfig } from 'vite-plus'
export default defineConfig({
run: {
tasks: {
hello: { command: 'echo hello' }
}
}
})
System Info
$ vp env current
Node.js:
Version 24.22.0
Source lts
Installed true
Mode managed
Package Manager:
Name bun
Version 1.4.3
Source packageManager
Installed true
Mode managed
$ vp --version
vp v1.3.0
Local vite-plus:
vite-plus v1.3.0
Tools:
vite v8.3.4
rolldown v1.2.14
vitest v5.0.5
oxfmt v0.73.0
oxlint v1.88.0
oxlint-tsgolint v7.0.2004
tsdown v0.23.1
Environment:
Package manager bun v1.4.3
Node.js v24.22.0
macOS 27.0.1 (arm64). I removed the local paths from the vp env current output.
Used Package Manager
bun
Logs
vp run probe, with the failing vite.config.ts. It printed the last line without waiting for Enter:
$ node probe.mjs ⊘ cache disabled
Waiting for one byte on stdin. Press Enter.
stdin is non-blocking: EAGAIN
vp run up, with the failing vite.config.ts and no key pressed. ANSI escape codes are removed:
$ vp update --interactive --latest ⊘ cache disabled
bun update --interactive v1.4.3 (c6da4a4d3)
? Select packages to update - …
dependencies Current Target Latest
❯ □ is-number 6.0.0 6.0.0 7.0.0
✓ Selected 0 packages to update
! No packages selected for update
Validations
- Read the Contributing Guidelines.
- Check that there isn't already an issue for the same bug.
- Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
- The provided reproduction is a minimal reproducible example.
- Linguagem predominante
- Rust
- Estrelas
- 6.3k
- Forks
- 283
- Merge médio
- 1d 12h
- PRs com merge (30d)
- 235
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de voidzero-dev/vite-plus
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
voidzero-dev/vite-plus#3219 ·
Mantenedores costumam responder em até 1 dia
-
pending triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
voidzero-dev/vite-plus#2882 · 2 comentários ·
Mantenedores costumam responder em até 1 dia
-
pending triage
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
voidzero-dev/vite-plus#3218 ·
Mantenedores costumam responder em até 1 dia
-
LSP loads vite.config.ts with the server's cwd as rootTalvez já em andamento @leaysgur assumiu hoje. Abertapending triage
voidzero-dev/vite-plus#3217 · 1 responsável ·
Mantenedores costumam responder em até 1 dia
-
vp migrate doesn't flag esbuild-specific config (minify: "esbuild") — migrated project fails to build on Vite 8Talvez já em andamento @john-okeefe assumiu há 2 dias. Abertacontribution welcome
voidzero-dev/vite-plus#3176 · 1 reação · 1 responsável ·
Mantenedores costumam responder em até 1 dia
Todas as issues de voidzero-dev/vite-plus
Issues semelhantes
-
checkpoint/verify/rebuild_indexes on a thread holding a WriteTransaction deadlock instead of INT-001Abertabug known-issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
project-minigraf/minigraf#734 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
Mantenedores costumam responder em até 4 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
Nimblesite/lspkit#26 ·
Mantenedores costumam responder em até 1 dia