Uh oh!
There was an error while loading. Please reload this page.
Template literal types for template literal expressions - #41891
Merged
Conversation
ahejlsberg
requested review from
DanielRosenwasser, RyanCavanaugh and weswighamDecember 9, 2020 04:00
This was referenced Dec 9, 2020
DanielRosenwasser
requested changes
Dec 9, 2020
DanielRosenwasser
left a comment
Member
There was a problem hiding this comment.
The implementation looks good apart from the API stuff.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ahejlsberg
commented
Dec 9, 2020
MemberAuthor
@typescript-bot test this |
Contributor
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 96885c3. You can monitor the build here. |
Contributor
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! |
Contributor
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 96885c3. You can monitor the build here. |
Contributor
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 96885c3. You can monitor the build here. |
typescript-bot
commented
Dec 9, 2020
Contributor
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
typescript-bot
commented
Dec 9, 2020
Contributor
@ahejlsberg Here they are:Comparison Report - master..41891
System
Hosts
Scenarios
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ahejlsberg
commented
Dec 9, 2020
MemberAuthor
Test suites revealed that template literal types didn't consistently have a |
ahejlsberg
commented
Dec 9, 2020
MemberAuthor
@typescript-bot test this |
Contributor
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 5cf670b. You can monitor the build here. |
Contributor
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
ahejlsberg
commented
Dec 9, 2020
MemberAuthor
DT run is clean. Performance looks fine. Latest RWC run shows a few errors that shouldn't have been errors disappearing. |
ahejlsberg
commented
Dec 10, 2020
MemberAuthor
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 declareconstsomeStringArray: 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: declareconstsomeStringArray: 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: declareconstsomeArray: 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 |
ahejlsberg
commented
Dec 10, 2020
MemberAuthor
I'm going to mark this as a breaking change given what we're seeing in the user test suites. |
weswigham
commented
Dec 12, 2020
Member
Oof, apparently breaky enough to break our own build post-LKG. Namely, we have constinternal=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. |
weswigham
commented
Dec 12, 2020
Member
#41942 is up with a fix to the build break, assuming we don't want to do anything with this change, |
5 tasks
jcalz
commented
Feb 8, 2021
Contributor
pedrodurek
commented
Feb 19, 2021
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 freeto 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.