IsLiteral: Adding strictStringCheck option

[benzaria]

Adding strictStringCheck option to control the behavior of IsStringLiteral against wide patterns such as template literals (on${string}), or utility type results like Uppercase<string>.

• When strictStringCheck is true, types like on${string} or Uppercase<string> are considered not string literals.
• When set to false, those cases are considered valid literals.

Fixes #1145

[benzaria]

@som-sm I think this is a great way to solve the problem we encounter in ExtractLiterals, i hope u review this ASAP so i can rebase the ExtractLiterals branch

[som-sm]

@benzaria Please keep the PRs focused on a single change. In this case, just add the strict option to IsLiteral and IsStringLiteral, and avoid fixing any unrelated types in the same PR.

Keeping changes atomic makes it much easier to review and provide feedback. Hope that makes sense!

[benzaria]

@som-sm I want to point out that the issue u mentioned in the review for the boolean behavior getting removed from IsStringLiteral, actually its coming from LiteralCheck type which does not distribute the type giving.
But in the other hand _IsStringLiteral helper type does distribute, So this inconsistency in behavior is not reliable, at least for the moment because all other types return false on union.
So I can remove IsTrue from this line to bring the boolean back but that will only be in Strict true (uses _IsStringLiteral), if it's not the LiteralCheck type will return false anyway.

My thought on this is keeping the false for now until finding a solution for LiteralCheck type! Maybe @sindresorhus can give an opinion on this as well ?

[som-sm]

So I can remove IsTrue from this line to bring the boolean back but that will only be in Strict true (uses _IsStringLiteral), if it's not the LiteralCheck type will return false anyway.

Ideally, all the logic should remain in _IsStringLiteral, and it should receive the ResolvedOptions from IsStringLiteral.

export type IsStringLiteral<S, Options extends IsStringLiteralOptions = {}> =
	ApplyDefaultOptions<IsStringLiteralOptions, DefaultIsStringLiteralOptions, Options> extends infer ResolvedOptions extends Required<IsStringLiteralOptions>
		? IfNotAnyOrNever<S,
			_IsStringLiteral<CollapseLiterals<S extends TagContainer<any> ? UnwrapTagged<S> : S>, ResolvedOptions>,
			false, false>
		: never;

type _IsStringLiteral<S, Options extends Required<IsStringLiteralOptions>> =
	// If `T` is an infinite string type (e.g., `on${string}`), `Record<T, never>` produces an index signature,
	// and since `{}` extends index signatures, the result becomes `false`.
	S extends string
		? Options['strict'] extends false
			? LiteralChecks<S, string>
			: {} extends Record<S, never>
				? false
				: true
		: false;

And, this would ensure you get boolean even after using LiteralChecks, because the type would’ve been distributed before reaching LiteralChecks. So, the only change required here was to pass ResolvedOptions from IsStringLiteral to _IsStringLiteral, and then call LiteralChecks when strict is false.

[benzaria]

@som-sm i did ur suggestion. and also later on we can modify LiteralChecks to do the distribution for other types.

[benzaria]

@som-sm Hi, I hope u review the latest changes, and maybe take a look at #1158 as well.

[som-sm]

@benzaria Please address this #1153 (comment), this PR still seems to have changes that are not related to adding strict option to IsLiteral and IsStringLiteral.

[benzaria]

This PRs will be ready to review after Merge of ExtendsStrict branch

[benzaria]

@benzaria Please address this #1153 (comment), this PR still seems to have changes that are not related to adding strict option to IsLiteral and IsStringLiteral.

@som-sm Are u referring to the changes on IsNumericLiteral ?

[som-sm]

Please move Fixing unpredictable behaviors part in a separate PR.

[som-sm]

Run it through AI please.

[benzaria]

Check the new doc ! and tell me if it any good

[som-sm]

strict name is ambiguous here, since IsLiteral doesn't involve just strings.

I was thinking of referencing the IsStringLiteralOptions in IsLiteralOptions, so we'd not have to repeat ourself.

type IsStringLiteralOptions = {
	strict?: boolean;
};

/**
Supports all {@link IsStringLiteralOptions} options.
*/
type IsLiteralOptions = IsStringLiteralOptions;

In future if we add options to any other Is*Literal type, we can simply & it here and add a link, like:

/**
Supports all {@link IsStringLiteralOptions} and {@link IsNumberLiteralOptions} options.
*/
type IsLiteralOptions = IsStringLiteralOptions & IsNumberLiteralOptions;

Only downside is that we would have ensure there's no conflicting names. @sindresorhus WDYT?

[benzaria]

That sound amazing actualy. great thinking !

[sindresorhus]

👍

[benzaria]

I Did it, and test it with and other options and worked flawlessly

[benzaria]

@sindresorhus @som-sm Hey guys what should we keep the current strictStringCheck options name as is or change it?
here are some suggestion I'm thinking of:

• strictStringLiteral
• strictLiteralCheck

[sindresorhus]

strictStringLiteral

👍