feat(logs): add inline JSON syntax highlighting for log attributes

[JoshuaKGoldberg]

Add inline syntax highlighting for JSON embedded within log attribute values in the expanded attribute tree view.

Previously (LOGS-400), only attribute values that were entirely valid JSON got pretty-printed with StructuredEventData. Values like This is my JSON: {"it": "would be", "nice": ["to", "highlight"], "this": true} rendered as plain text. Now, the JSON portion gets Prism-based syntax colorizing inline — keys, strings, numbers, booleans, and punctuation each get their own color — without adding newlines or changing the layout.

The JSON extraction logic lives in a standalone utility (extractJsonFromText) that uses string-aware bracket matching to correctly handle braces inside quoted strings and escape sequences — unlike existing npm packages (balanced-match, extract-json-from-string) which break on these cases. I intentionally set this up so that it acts like a standalone importable utility. It'd be nifty if we could publish this as its own package...

Fixes LOGS-636

Made with Cursor

[linear-code]

LOGS-636 Investigate expand JSON log syntax highlighting to inline

[scttcper]

not sure if it would help but we do have the https://npmx.dev/package/jsonrepair package

[JoshuaKGoldberg]

Oh cool good to know! I don't think we can use that here, since we don't want to modify the log strings. The intent is just to syntax highlight any valid JSON if it's there.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Unmatched bracket aborts scanning, skipping later valid JSON

Medium Severity

When findMatchingBracket returns -1 (unmatched bracket), the scanner pushes all remaining text as a single text segment and breaks out of the loop. This causes any valid JSON appearing later in the string to be silently missed. For example, parse [ error {"status": 500} would treat everything from [ onward as plain text because [ has no matching ], even though {"status": 500} is valid extractable JSON. The JSON.parse failure path correctly advances just one character and continues scanning — the matchEnd === -1 path needs the same treatment instead of giving up on the rest of the input.

 

[JoshuaKGoldberg]

I think this is fine. It's an edge case and syntax highlighting is not a critical UI feature.

[cursor]

Multiline JSON loses newlines during Prism rendering

Low Severity

JsonSegment renders each Prism line inside a Fragment with no newline character between lines. usePrismTokens splits on \n and consumes the newline characters during tokenization (in splitTokenContentByLine). So when a JSON segment contains actual newlines (e.g. {\n "key": "value"\n}), the rendered output collapses them — displaying { "key": "value"} instead. The white-space: pre-wrap on InlineCode doesn't help because the \n characters are already gone. Other callers of usePrismTokens typically render a line break element between lines.

 

[JoshuaKGoldberg]

I'll look into this on Monday.

[JoshuaKGoldberg]

I believe this is already a bug on production.