-
-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Describe the bug
I've observed an inconsistency in how string literals containing newline characters are processed. Specifically, this issue seems to be related to the evaluation order of types, which leads to inconsistent behavior across similar test cases.
To Reproduce
The current implementation seems to struggle with distinguishing newline characters inside quoted strings from those outside them. This inconsistency suggests that the type definitions may need refinement to ensure accurate parsing of CSV-like data structures.
Case 1: Correct Behavior
In the first case, the type evaluation correctly handles the newline (\n
) character within a quoted string and does not treat it as a line separator. The \r\n
sequence outside of the quoted string is correctly identified as a separator.
// case 1
expectTypeOf<SplitNewline<'"a\n"\r\nb\r\nc'>>().toMatchTypeOf<
['"a\n"', "b", "c"]
>();
Case 2: Incorrect Behavior
In the second case, the type evaluation incorrectly splits the string on the \r\n
sequence inside the quoted string. This sequence should be considered part of the quoted string and not as a separator.
// case 2
expectTypeOf<SplitNewline<'"a\r\n"\r\nb\r\nc'>>().toMatchTypeOf<
['"a\r\n"', "b", "c"]
>();
Expected behavior
The type SplitNewline should correctly handle newline characters inside quoted strings and only treat newline sequences as separators when they are outside of quoted strings.
Activity