All versions of npm init hang on Node 8.1.0

[iarna]

• Version: 8.1.0
• Platform: Darwin
• Subsystem: Unsure

To reproduce, with Node 8.1.0 and any version of npm (we've explicitly tested w/ 2, 3, 4 & 5):

$ npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg> --save` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
name: (x) 
version: (1.2.0) 

At the prompt for version Node stops accepting input and doesn't respond to ^Z or ^C. (It does respond to kill -STOP and kill -INT. Continuing the process after a STOP results in keyboard input being echoed but the process still does not run.)

[krokofant]

yarn behaves the same

[addaleax]

This was caused by 81ddeb9, /cc @gibfahn @jasnell

@mscdex I’m removing the v8.x label because this is an issue on master as well.

[Fishrock123]

I can't seem to reproduce on master or 8.1.0?

The WARN does seem to be on the wrong line though?

Press ^C at any time to quit.
package name: (npm-test) npm WARN init canceled
🐟  ~/D/h/npm-test>

[Fishrock123]

I'd be curious to see what e.g. the following patch prints pre/post 81ddeb9

diff --git a/lib/readline.js b/lib/readline.js
index 6a1ed150d7..6113846c91 100644
--- a/lib/readline.js
+++ b/lib/readline.js
@@ -1039,6 +1039,8 @@ function emitKeypressEvents(stream, iface) {
   } else {
     stream.on('newListener', onNewListener);
   }
+  iface.on('close', () => process._rawDebug('## CLOSE'))
+  stream.on('data', () => process._rawDebug('## DATA'))
   if (iface) {
     iface.once('close', () => { stream.removeListener('data', onData); });
   }

[addaleax]

@Fishrock123 I’m not sure I’m reading your output correctly – you first have to enter the package name, only after that I can’t quite anymore.

[iarna]

@addaleax lol! I opened this issue and turned to @zkat and said "I bet Anna sees this and knows exactly the cause"

[Fishrock123]

Oops. 🙊

It appears a close is emitted after pressing enter under normal circumstances...

package name: (npm-test) ## DATA

## CLOSE
version: (0.0.0) ## DATA

description: ## DATA
npm WARN init canceled

[addaleax]

@Fishrock123 Apparently, npm init (or rather the read module) creates a new readline instance per question that it asks…

@jasnell You’re right, reverting is a bit silly, this is easy to fix (in a somewhat obvious way, in hindsight): okay, no, the original patch was incorrect and should be reverted.

--- a/lib/readline.js
+++ b/lib/readline.js
@@ -1040,7 +1040,11 @@ function emitKeypressEvents(stream, iface) {
     stream.on('newListener', onNewListener);
   }
   if (iface) {
-    iface.once('close', () => { stream.removeListener('data', onData); });
+    iface.once('close', () => {
+      stream[KEYPRESS_DECODER] = null;
+      stream[ESCAPE_DECODER] = null;
+      stream.removeListener('data', onData);
+    });
   }
 }

I’ll have a PR and tests up in a bit.

@iarna Naaaaw! 💙

[Fishrock123]

Apparently, npm init (or rather the read module) creates a new readline instance per question that it asks…

While that seems inefficient, readline does apparently emit close at the end of each line: https://nodejs.org/dist/latest-v8.x/docs/api/readline.html#readline_event_close

(Which leads me to believe the patch above may be a bit inefficient too? We can discuss in a PR.)

[addaleax]

While that seems inefficient, readline does apparently emit close at the end of each line: https://nodejs.org/dist/latest-v8.x/docs/api/readline.html#readline_event_close

Are you sure? I don’t really read the docs as stating that…

[jasnell]

That definitely seems like a bug then. It really should not be emitting close at that point. Let's see if we can fix that issue quickly before reverting the other commit

[addaleax]

It really should not be emitting close at that point.

It doesn’t, it’s the read module that closes the readline instance explicitly after having read the answer.

[addaleax]

PR to fix/revert: #13560

[131]

Following sample code is broken, waiting for you @addaleax !

const readline = require('readline')

function prompt(opts, cb) {
  var input = process.stdin
  var output = process.stdout
  var terminal = !!(output.isTTY)
  var rlOpts = { input, output, terminal }
  var rl = readline.createInterface(rlOpts)
  rl.setPrompt(opts.prompt)
  rl.prompt()
  rl.on('line', function(line){
    rl.close()
    cb(null, line);
  })
}
const foo = function() {
  prompt( {prompt : "#>" }, function(err, line ){
    console.log("Got", err, line);
    foo();
  })
}

foo();

[gibfahn]

@131 see #13560 (comment), it'll be fixed in the next v8.x release, scheduled for next Tuesday.

[Bamieh]

i'm still facing this issue guys

[addaleax]

@Bamieh As described above, upgrade Node to the latest version and you will be fine.

[Bamieh]

@addaleax true, it gets fixed when upgrading node, i only upgraded npm before and it didnt work. thanks

[gezquinndesign]

This is still affecting the loopback-cli

It freezes after giving the application name...

node version - v10.7.0
npm version=6.1.0
loopback- 4.2.0
OS- windows10

anyone help please?

Thanks