Description
Acknowledgement
- I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.
Comment
by @acutmore, @molisani, @dragomirtitian
We have completed our evaluation of the impact of upgrading to TypeScript 5.4 on our codebase. Here are our findings.
This is shaping up to be a medium impact release. The following table lists changes that affected our codebase, and where appropriate a link to a separate Issue:
🟢 = positive breaking change
🔴 = negative breaking change
🐛 = compiler bug
| Change | Affects | Release notes | Packages affected | Reported as |
|---|---|---|---|---|
| More Accurate Conditional Type Constraints (with optional property) 🟢 | Type Checking | Yes | ~95% (transitive)(3 direct) | |
| Preserved Narrowing in Closures Following Last Assignments 🟢 | Type Checking | Yes | 2 | |
| Errors When Type-Only Imports Conflict with Local Values 🟢 | Type Checking | Yes | 2 | |
...any[] becoming ...unknown[] 🐛 |
Type Checking | 2 | #57389 | |
| New circular type alias error 🐛 | Type Checking | 1 | #57357 | |
instanceof type narrowing change due to .prototype inference 🟢 |
Type Checking | 1 | #57397 | |
| Interface merging no longer masking wider return type 🟢 | Type Checking | 1 | n/a | |
| Inline type import not utilizing existing import 🔴 | .d.ts emit | 8 | #57415 |
More Accurate Conditional Type Constraints (with optional property)
Comes from: #56004
This impacted most of our packages because it caused a new error in core packages that almost everything else depends on, and we don't skipLibChecks.
Looking at the error it is correctly identifying that the type may not be valid when instantiated, so is a good error. We have since improved these types to have a more accurate constraint.
Side-note: This particular pattern only errors when exactOptionalPropertyTypes is disabled (we keep this as the default).
Interface merging no longer masking wider return type
Bisects to: #55447
This bug fix impacted one package. This error does also appear in TS 5.3 if the order of a union is changed - so 5.4 is now more reliably catching this regardless of union order.
Inline type import not utilizing existing import
Bisects to: #56857
This negatively impacted 8 packages. In some cases TypeScript is no longer utilizing existing import statements for declaration emit, and instead adding new inline type imports. This triggers an error in our build pipeline where we assert that .d.ts imports only resolve to a package's public entrypoints.