[ID] `--isolatedDeclarations` disallows `const` initialized with a regex literal

[Conaclos]

🔍 Search Terms

• isolatedDeclarations
• isolated declaration

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I an unsure if it is a bug or a feature request...

An exported const without type annotation and initialized with a regex literal triggers the following error error TS9010: Variable must have an explicit type annotation with --isolatedDeclarations. in isolated declaration mode.

If I understand correctly, isolated declaration should allow unannotated const initialized with any literal?

📃 Motivating Example

See an example on the playground.

💻 Use Cases

This could avoid a trivial type annotation.

[jakebailey]

This would require us to hardcode the type of a regex expression, no? Since regexes aren't an intrinsic and aren't valid initializers in dts?

I guess it could always just be RegExp, so long as that type name hasn't been reused. It's not like "number" or a literal value where the type name is reserved.

[RyanCavanaugh]

This seems like the same situation as any other literal type, except that regex literal types don't exist, so we can safely write X: RegExp (yeah, barring shadowing)

[jakebailey]

Just hope we never add stricter RegExp types...

Does the quick fix at least suggest adding : RegExp in the latest nightly?

[jakebailey]

The fix does work, so this issue is mainly about whether or not ID should allow this inference.

[weswigham]

Just hope we never add stricter RegExp types...

#32098 is really close with our recent regex parsing changes in, but I don't think that'd block this, actually. Whenever we start emitting a RegExpWithNamedGroups<["a", "b", "c"]> or whatever instead of a plain RegExp type, the correct type should still be trivially determinable just by parsing the named capture groups out of the regex.

On the flip side, since I'm pretty sure that once we have more detailed types for the literal like that, they actually probably need widening behaviors like other literal types, so if you do

x = /(?<a>a)/
x = /(?<b>b)/

you want x to be RegExp and not RegExpWithNamedGroups<["a"]> with an error on the second assignment. In any case, the future correct output is going to be one of : RegExp, : RegExpWithNamedGroups<["a"]> (or whatever it's formatted as), or even = /re raw literal/ (if we decided we do need full literal freshness), the correct one of which should be statically determinable from the syntax and what we support at the time.