denoland/deno

[BUG] v2.3.4 regression: enquirer package loses first character on subsequent prompts

Opened this issue · 9 comments

esroyo commented

Summary

Deno v2.3.4 introduced a regression where the enquirer npm package loses the first character when typing responses to the second and subsequent prompts in a sequence.

Root Cause

Suspected cause: "fix(ext/node): prevent stdin double read (#29353)"

Reproduction

// enquirer_regression.ts
import Enquirer from "npm:enquirer@^2.4.1";

const { prompt } = Enquirer;

console.log("=== Deno v2.3.4 Enquirer Regression Test ===");

const first = await prompt({
  type: 'input',
  name: 'first',
  message: 'First prompt - Type "hello"'
});

const second = await prompt({
  type: 'input', 
  name: 'second',
  message: 'Second prompt - Type "world"'
});

console.log('Results:', first, second);

Run: deno run --allow-read --allow-net enquirer_regression.ts

Expected Behavior

First prompt - Type "hello": hello
Second prompt - Type "world": world
Results: { first: 'hello' } { second: 'world' }

Actual Behavior in v2.3.4

When typing the second prompt response:

  • First character typed disappears
  • User must type each key twice to see characters appear
  • Final result missing first character
First prompt - Type "hello": hello
Second prompt - Type "world": orld
Results: { first: 'hello' } { second: 'orld' }

Environment

  • Working: Deno v2.3.3 and earlier
  • Broken: Deno v2.3.4
  • Package: enquirer@2.4.1
  • Pattern: First prompt works fine, 2nd+ prompts lose first character

Additional Notes

  • Cannot create minimal reproduction: Multiple attempts to reproduce this issue with dependency-free readline/keypress patterns were unsuccessful
  • Issue is library-specific: The bug appears to be a subtle interaction between the v2.3.4 "prevent stdin double read" fix and enquirer's specific stdin/readline implementation patterns
  • Reliable reproduction: While minimal reproductions failed, the enquirer case reliably demonstrates the regression across different environments
  • Potential wider impact: Other prompt libraries using similar readline patterns may be affected

Impact

Breaks interactive CLI applications using enquirer, making them unusable for multi-prompt workflows.

esroyo commented

Probably related to (dupe of):

liby commented

I'd like to clarify that Deno v2.3.3 is NOT working correctly either - it has a different but related issue.

On Deno v2.3.3:
When running scripts with sequential permission prompts, the second prompt becomes
completely unresponsive:

  • First permission prompt (TERM_PROGRAM): Works fine, can type and respond
  • Second permission prompt (TERM): Completely frozen, cannot type anything at all

The statement "Working: Deno v2.3.3 and earlier" in the issue description appears to be incorrect based on my testing.

esroyo commented

@liby In my case there is something very confusing: after installing 2.3.4, the binary reports itself as being 2.3.3 (when It is not):

$ sudo deno upgrade 2.3.3

Current Deno version: v2.5.1
Downloading https://github.com/denoland/deno/releases/download/v2.3.3/deno-x86_64-unknown-linux-gnu.zip
Deno is upgrading to version 2.3.3

Upgraded successfully to Deno v2.3.3 (stable)

$ deno --version
deno 2.3.3 (stable, release, x86_64-unknown-linux-gnu)
v8 13.7.152.6-rusty
typescript 5.8.3

$ which deno
/usr/bin/deno

$ md5sum /usr/bin/deno 
04c370dfe77443452a29ad4e7ff71718  /usr/bin/deno

$ sudo deno upgrade 2.3.4
Current Deno version: v2.3.3
Downloading https://github.com/denoland/deno/releases/download/v2.3.4/deno-x86_64-unknown-linux-gnu.zip
Deno is upgrading to version 2.3.4

Upgraded successfully to Deno v2.3.4 (stable)

$ deno --version
deno 2.3.3 (stable, release, x86_64-unknown-linux-gnu)
v8 13.7.152.6-rusty
typescript 5.8.3

$ md5sum /usr/bin/deno 
242c734794091c7ad0246ab29c200d7d  /usr/bin/deno

Confusing. But gets worse as after installing 2.3.4, you can not go back to 2.3.3 (directly):

$ sudo deno upgrade 2.3.3

Current Deno version: v2.3.3
Version 2.3.3 is already installed

$ md5sum /usr/bin/deno 
242c734794091c7ad0246ab29c200d7d  /usr/bin/deno

At least for my example case, the real Deno 2.3.3 (the first one) works fine.
And Deno 2.3.4 (which appears to be 2.3.3 once installed) contains the bug as reported in this issue.

  • 👀1
sigmaSd commented

This is suddenly fixed in 2.5.3

liby commented

I think you must be mistaken. I neither saw the relevant fix code in version 2.5.3, nor did the issue disappear in my local tests.

Image
sigmaSd commented

AhI might be wrong then I'll check it again later but the gemini issue did get fixed I tested that one more

sigmaSd commented

Actually this makes me suspect that the fix was in Gemini side, I have a minimum reproduction in that issue , Ican test that later

sigmaSd commented

This indeed was fixed for now in gemini side, the minimal reproduction here #30145 (comment) still gets stuck

esroyo commented

I think you must be mistaken. I neither saw the relevant fix code in version 2.5.3, nor did the issue disappear in my local tests.
Image

Same here ✔️