Inconsistent handling of whitespace in string in template literal types

[annacb40]

Bug Report

🔎 Search Terms

template literal types
template literal whitespace
template literal spaces
template literal strings

🕗 Version & Regression Information

This changed between versions 4.0.5 and 4.1.5. I think this variety of type definition was not supported prior to 4.1.5.

⏯ Playground Link

Playground link with relevant code

💻 Code

type StringWithNumberX = `${string} ${number}x`;
type CommaSepStringWithNumberX = `${StringWithNumberX}, ${StringWithNumberX}`;
type CommaStringSepStringWithNumberX = `${StringWithNumberX}, ${string}${StringWithNumberX}`;

const commaSepStringWithNumberX: CommaSepStringWithNumberX = 'foo 4x, bar 5x';
const stringWithNumber: StringWithNumberX = 'foo 5x';

const emptyString: StringWithNumberX = ' 5x';
const moreSpacesBetween: StringWithNumberX = 'foo    5x'; // seems consistent given https://github.com/microsoft/TypeScript/issues/46109
const suffixSpaces: StringWithNumberX = 'foo 5   x' // seems consistent given https://github.com/microsoft/TypeScript/issues/46109

// Tabs and new lines are included with string, but spaces are not
const prefixNewLine: StringWithNumberX = '\nfoo 5x'; 
const newLineInString: StringWithNumberX = 'foo\nbar 5x';
const newLineBetween: StringWithNumberX = 'foo \n 5x' 
const suffixNewLine: StringWithNumberX = 'foo 5x\n'; // new line is not ignored
const prefixTab: StringWithNumberX = '\tfoo 5x'; 
const tabInString: StringWithNumberX = 'foo\tbar 5x';
const tabBetween: StringWithNumberX = 'foo \t 5x' 
const suffixTab: StringWithNumberX = 'foo 5x\t'; // tab is not ignored

// Cases that seem inconsistent
const spacesInString: StringWithNumberX = 'foo bar 5x'; // spaces in string are not allowed?
const prefixSpaces: StringWithNumberX = '   foo 5x'; // spaces at start of string are not allowed?

const extraSepSpace: CommaSepStringWithNumberX = 'foo 4x,  bar 5x'; // extra space isn't included with second string?
const extraSepSpace2: CommaStringSepStringWithNumberX = 'foo 4x,  bar 5x'; // adding the string in the separator lets me add exactly one space in between
const twoExtraSepSpace: CommaStringSepStringWithNumberX = 'foo 4x,   bar 5x'; // adding the string in the separator lets me add exactly one space in between

🙁 Actual behavior

${string} in a template literal type will accept tabs and/or new lines anywhere in the string, but does not accept spaces within the string.

🙂 Expected behavior

${string} should allow spaces within the string.

[DanielRosenwasser]

Maybe I'm missing some part of your examples - but I think this just has to do with greedy string matching. When TypeScript encounters a template string type like

`${string}FOO${...}`

there is no back-tracking involved in trying to solve for all places where a FOO will occur. The first one wins, and everything up until that point will be matched against that string.

So please correct me if I'm missing something, but I don't think this has anything to do with whitespace.

[annacb40]

@DanielRosenwasser Maybe I am missing something, but take the example of const spacesInString: StringWithNumberX = 'foo bar 5x';.... I'm not sure how this would involve backtracking at all? It appears to me there is only one instance of
${number}x, and for some reason "foo bar" is not then matching for string.

So "foo bar" would not match a string, but "foo" does.....it really seems that the difference here is the space.

[annacb40]

@DanielRosenwasser I wonder, are you looking at the playground and not just the code sample in the issue? The playground shows type errors for several cases where I would not expect type errors. The lines with type errors are 16, 20, 23, 24, 26, and 28. Lines 16 and 20 failing seems consistent. The others do not, specifically because of the way spaces are being treated.

[fatcerberus]

The space makes a difference because your pattern contains one. Daniel is saying that TypeScript is matching foo (with the space) with ${string} , it is then unable to match bar 5x with ${number}x and gives up. It won’t go back and try to match with a larger ${string}.

[microsoft-github-policy-service]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[microsoft-github-policy-service]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[microsoft-github-policy-service]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[microsoft-github-policy-service]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[fatcerberus]

This new bot sucks.