Inconsistent Handling of Newline Characters in SplitNewline Type

[kamiazya]

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.