Module js_json 

JSON.parse failures, worded the way V8 words them.

One route hands a client-supplied JSON string to a parser and lets the failure escape as the response’s error message: the row browser’s filters query parameter. The reference is Node, so that message is V8’s parser diagnostic, and a client that shows it to a person shows V8’s wording. This module reproduces that wording from serde_json’s.

It is a translation of one parser’s diagnostics into another’s, not a parser, so it covers the shapes a malformed parameter actually arrives in and no more:

input	message
truncated or empty	Unexpected end of JSON input
a character no value can start with	Unexpected token 'x', "…" is not valid JSON
anything after a complete value	Unexpected non-whitespace character after JSON at position N
a string with no closing quote	Unterminated string in JSON at position N
a missing , or ] between array elements	Expected ',' or ']' after array element in JSON at position N
a key that is not a string	Expected property name or '}' in JSON at position N

Anything else falls back to the unexpected-token wording, which is V8’s own most common answer. Positions are counted in characters; V8 counts UTF-16 code units, so a message pointing past an astral character would differ. Every row of the table above is a case in the catalog parity gate.

Where this stops, on purpose. A document that runs out inside a container is the one family not reproduced. V8 words those by what the parser was waiting for — a property name, a :, a , or ], a , or } — and serde_json reports only which container was open, so telling [1 from ["a" from {"a" would mean writing a second JSON scanner to recover a parse state. Those all answer Unexpected end of JSON input here. The status, the ok: false, and the shape are identical either way; only the sentence differs, and only for a filters value no client builds — the dashboard sends JSON.stringify output, which never truncates.

Functions

parse

JSON.parse(raw), with V8’s message on failure.