Node REPL says "SyntaxError: unexpected symbol :" when parsing multi-line string-keyed objects (e.g. JSON)

[alexch]

• Version: 10.3.0 and 10.5.0
• Platform: MacOS
• Subsystem: CLI

When entering (or pasting) a multi-line object with string keys -- e.g. any JSON object -- the Node CLI correctly asks for more input with a ... prompt, but then incorrectly fails with a SyntaxError: Unexpected token :.

Example:

$ node --version
v10.3.0
$ node
> {"foo":false}
{ foo: false }
> {
... "foo":false
"foo":false
     ^

SyntaxError: Unexpected token :

This problem only occurs with string keys; bare keys work fine:

> {
... foo:false
... }
{ foo: false }

reproduced on 10.5.0 as well

This is an important issue because JSON objects are all string-keyed, and this parsing bug makes it impossible to copy and paste valid, pretty-printed JSON into the console.

[addaleax]

I’m not sure what changed in Node (v8.x doesn’t have this issue), but I think I can answer why quoted strings vs unquoted keys matter: In the case of un-quoted “keys”, JS code like { foo: false } is not, like one would expect, parsed as an object.

Instead, it’s parsed as a block, and the foo: bit is parsed as a label for the statement false.

This doesn’t happen with single-line statements because Node.js hacks around that and first tries to wrap the code in parentheses, i.e. ({ foo: false }), which would be parsed differently (as an object).

This is an important issue because JSON objects are all string-keyed, and this parsing bug makes it impossible to copy and paste valid, pretty-printed JSON into the console.

Yes, I think that’s an use case we should definitely support 👍

[alexch]

Good to know. Thanks to your explanation, I found a workaround: precede the pasted content with x=:

> x={
... "foo" : false
... }
{ foo: false }

[vsemozhetbyt]

This is not reproducible on https://nodejs.org/download/nightly/v10.0.0-nightly20180309099e621648/ and is reproducible on https://nodejs.org/download/nightly/v10.0.0-nightly2018031198a14e026b/. As per repl.js history, these commits are merged between these versions:

4893f70#diff-b13d72249263845d8e8341db0426f9d3

ebfa8b1#diff-b13d72249263845d8e8341db0426f9d3

[rubys]

The regression was indeed caused by ebfa8b1#diff-b13d72249263845d8e8341db0426f9d3

Attempting to fix this by partially reverting the change by adding in:

if (message.startsWith('Unexpected token')) return true;

does indeed fix this problem, but causes other problems. In particular, the following test will fail:

ebfa8b1#diff-293fefe850253c8c28e2481c0b7f76e2L647

[vsemozhetbyt]

cc @nodejs/repl

[antsmartian]

Ok looks like we need this feature, which is breaking now. I'm not sure about the following test case and its importance over here: https://github.com/nodejs/node/blob/master/test/parallel/test-repl.js#L166. But adding the change like @rubys pointed will break the above test case. Not sure, we can handle both the cases in code, because the above test case expects the expression shouldn't cross the lines(which is what we need). May be we need to take a call on the use cases and features?

[rubys]

Looking at the code, I don't think it needs to be an either/or. If the use case is to ensure that an incomplete JSON object literal is to be treated as "recoverable", we would need to either extend the isCodeRecoverable function (or create a new function specific to JSON) that understands JSON syntax.

Just so it is clear: JSON syntax is supported when used in the context of a statement (say, an assignment or if statement) is fully supported, the only thing that is not currently supported is input that starts with (or consists exclusively of) a naked JSON object literal.

[BridgeAR]

Fixed by #21805