fix(lib): Fix RegExp constructor with string|RegExp and flags

[ExE-Boss]

Previously:

export function replace(str: string, from: string | RegExp, to: string): string {
	return String(str).replace(RegExp(from, 'g'), to);
}

Would result in:

error TS2345: Argument of type 'string | RegExp' is not assignable to parameter of type 'string'.
  Type 'RegExp' is not assignable to type 'string'.

 return String(str).replace(RegExp(from, 'g'), to);
                                   ~~~~

This fixes that.

See also: #14107

---

review?(@sandersn)

[ExE-Boss]

Obviously a less band‑aid solution would be identifying constructors that can be merged and dynamically merging them for union type calls, but I don’t really know how to do that.

[sandersn]

Would you mind explaining the problem more thoroughly. Normally we discuss a change like this with an issue, but this is minor enough it might be OK just to have a thorough explanation of the problem and the fix in the PR description.

[ExE-Boss]

@sandersn

The issue here is that TypeScript doesn’t actually consider the two following cases equal:

interface RegExpConstructor {
	new (pattern: RegExp, flags?: string): RegExp;
	(pattern: RegExp, flags?: string): RegExp;

	new (pattern: string, flags?: string): RegExp;
	(pattern: string, flags?: string): RegExp;
}

interface RegExpConstructor {
	new (pattern: RegExp | string, flags?: string): RegExp;
	(pattern: RegExp | string, flags?: string): RegExp;
}

---

The second one can be used with:

var pattern: RegExp | string;
var regexp = RegExp(pattern, 'g');

while the first one can’t.

---

#14107 describes this in more detail.

[sandersn]

@DanielRosenwasser do you have opinions? We need to look at the combined overload set and think about what happens if existing code starts resolving to a different overload.

[ExE-Boss]

@sandersn There shouldn’t be any difference, except that my above snippet will work for projects using ES2015 or newer without needing to cast from to any.

Ar do a pointless typeof ternary expression, which is so much worse because it introduces a runtime performance penalty, rather than just a source code ugliness penalty: #14107 (comment).

[RyanCavanaugh]

@typescript-bot test this

[typescript-bot]

Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at 6f64fed. You can monitor the build here. It should now contribute to this PR's status checks.

[sandersn]

@typescript-bot test this

[typescript-bot]

Heya @sandersn, I've started to run the extended test suite on this PR at 6f64fed. You can monitor the build here. It should now contribute to this PR's status checks.

[sandersn]

RWC and user test suites are clean. I'm surprised that we don't have coverage of this anywhere in the test suite, but it's clean too.