Template literal types for template literal expressions#41891
Merged
ahejlsberg merged 11 commits intomasterfrom Dec 12, 2020
Merged
Template literal types for template literal expressions#41891ahejlsberg merged 11 commits intomasterfrom
ahejlsberg merged 11 commits intomasterfrom
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
ahejlsberg
requested review from
DanielRosenwasser,
RyanCavanaugh and
weswigham
This was referenced Dec 9, 2020
DanielRosenwasser
requested changes
Dec 9, 2020
Member
DanielRosenwasser
left a comment
DanielRosenwasser
left a comment
There was a problem hiding this comment.
The implementation looks good apart from the API stuff.
tests/baselines/reference/emitExponentiationOperatorInTempalteString4.types
Show resolved
Hide resolved
Member
Author
|
@typescript-bot test this |
Collaborator
|
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 96885c3. You can monitor the build here. |
Collaborator
|
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! |
Collaborator
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 96885c3. You can monitor the build here. |
Collaborator
|
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 96885c3. You can monitor the build here. |
Collaborator
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
Collaborator
|
@ahejlsberg Here they are:Comparison Report - master..41891
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Member
Author
|
Test suites revealed that template literal types didn't consistently have a |
Member
Author
|
@typescript-bot test this |
Collaborator
|
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 5cf670b. You can monitor the build here. |
Collaborator
|
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 5cf670b. You can monitor the build here. |
weswigham
approved these changes
Dec 9, 2020
Member
Author
|
DT run is clean. Performance looks fine. Latest RWC run shows a few errors that shouldn't have been errors disappearing. |
Member
Author
|
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 |
Member
Author
|
I'm going to mark this as a breaking change given what we're seeing in the user test suites. |
Member
|
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. |
Member
|
#41942 is up with a fix to the build break, assuming we don't want to do anything with this change, |
5 tasks
Contributor
|
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? |
This was referenced Mar 24, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.