@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt
@typescript-bot perf test this

Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 96885c3. You can monitor the build here.

Heya @ahejlsberg, I've started to run the perf test suite on this PR at 96885c3. You can monitor the build here.

Update: The results are in!

Heya @ahejlsberg, I've started to run the extended test suite on this PR at 96885c3. You can monitor the build here.

Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 96885c3. You can monitor the build here.

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

@ahejlsberg
The results of the perf run you requested are in!

Test suites revealed that template literal types didn't consistently have a string constraint and therefore weren't assignable to String, Object, {}, and so on. Latest commits fix that.

@typescript-bot test this
@typescript-bot user test this

Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 5cf670b. You can monitor the build here.

Heya @ahejlsberg, I've started to run the extended test suite on this PR at 5cf670b. You can monitor the build here.

DT run is clean. Performance looks fine. Latest RWC run shows a few errors that shouldn't have been errors disappearing.

Three user test suites have new errors.

office-ui-fabric

We are now (correctly) reporting an error that was previously silenced because they're compiling with strictFunctionTypes off. Simplified example:

declare const someStringArray: string[];
someStringArray.map(key => !!true ? `foo${key}` : null).filter((s: string) => s);

We now report an error neither `foo${string` | null or string are assignable to each other. Previously it (unsoundly) succeeded because string is assignable to string | null.

We're also reporting an error on something similar to this:

declare const someStringArray: string[];
someStringArray.map(key => `foo${key}`).concat(someStringArray);  // string[] not assignable to `foo${string}`[]

Ideally this wouldn't be an error. The core issue is that concat types the array and the argument using the same type variable. It really should be T and U with the result typed as (T | U)[].

fp-ts

One new error that looks to be correct and simply a result of the stronger typing.

webpack

One new error on something similar to this:

declare const someArray: unknown[];
someArray.map(item => `foo${item}`).unshift("someString");  // Type "someString" not assignable to type `foo${string}`

Not much we can do about this. The array is now of type `foo${string}`[] instead of just string[], so it is an error to insert a value of type "someString".

I'm going to mark this as a breaking change given what we're seeing in the user test suites.

Oof, apparently breaky enough to break our own build post-LKG. Namely, we have

                    const internal = jsDocStyle ? `/**@internal*/` : `/*@internal*/`;
                    // ...
                    appendText(fs, sources[Project.second][Source.ts][Part.one], `
class normalC {
    ${internal} constructor() { }
    ${internal} prop: string;
    ${internal} method() { }
    ${internal} get c() { return 10; }
    ${internal} set c(val: number) { }
}
namespace normalN {
    ${internal} export class C { }
    ${internal} export function foo() {}
    ${internal} export namespace someNamespace { export class C {} }
    ${internal} export namespace someOther.something { export class someClass {} }
    ${internal} export import someImport = someNamespace.C;
    ${internal} export type internalType = internalC;
    ${internal} export const internalConst = 10;
    ${internal} export enum internalEnum { a, b, c }
}
${internal} class internalC {}
${internal} function internalfoo() {}
${internal} namespace internalNamespace { export class someClass {} }
${internal} namespace internalOther.something { export class someClass {} }
${internal} import internalImport = internalNamespace.someClass;
${internal} type internalType = internalC;
${internal} const internalConst = 10;
${internal} enum internalEnum { a, b, c }`);

in our test harness.

#41942 is up with a fix to the build break, assuming we don't want to do anything with this change,