-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Template literal types for template literal expressions #41891
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation looks good apart from the API stuff.
tests/baselines/reference/emitExponentiationOperatorInTempalteString4.types
Show resolved
Hide resolved
@typescript-bot 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 Here they are:Comparison Report - master..41891
System
Hosts
Scenarios
|
Test suites revealed that template literal types didn't consistently have a |
@typescript-bot 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-fabricWe are now (correctly) reporting an error that was previously silenced because they're compiling with declare const someStringArray: string[];
someStringArray.map(key => !!true ? `foo${key}` : null).filter((s: string) => s); We now report an error neither 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 fp-tsOne new error that looks to be correct and simply a result of the stronger typing. webpackOne 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 |
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, |
Hey @DanielRosenwasser, considering that changes here were rolled back, do we have a new issue opened for this? Or you'll reopen this one #41631? |
With this PR we infer template literal types for template literal expressions. The PR adheres to the same principles as those of literal types in #10676 and widening vs. non-widening literal types in #11126. For example:
As it is generally a breaking change for us to more strongly type anything, I'm marking this as a breaking change. In practice, the breaks appear to be rare and easy to fix.
Fixes #41631.