Repository navigation
Node REPL says "SyntaxError: unexpected symbol :" when parsing multi-line string-keyed objects (e.g. JSON) #21657
Description
Activity
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 statementfalse.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 👍
Reacted by Alex Chaffee and Joshua BurkeGood to know. Thanks to your explanation, I found a workaround: precede the pasted content with
x=:> x={ ... "foo" : false ... } { foo: false }- changed the title
[-]Node CLI says "SyntaxError: unexpected symbol :" when parsing multi-line string-keyed objects (e.g. JSON)[/-][+]Node REPL says "SyntaxError: unexpected symbol :" when parsing multi-line string-keyed objects (e.g. JSON)[/+]on Jul 4, 2018 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.jshistory, these commits are merged between these versions:- added a commit that references this issue
on Jul 7, 2018 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:
cc @nodejs/repl
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?
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
isCodeRecoverablefunction (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
ifstatement) 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.
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 aSyntaxError: Unexpected token :.Example:
This problem only occurs with string keys; bare keys work fine:
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.