Confusing diagnostics with exact optional property types (EOPT)
#56,682 opened on 2023幎12æ5æ¥
Repository metrics
- Stars
- Â (48,455 stars)
- PR merge metrics
-  (å¹³åããŒãž 6d 17h) (30d ã§ 9 merged PRs)
説æ
ð Search Terms
EOPT exact optional property types exactOptionalPropertyTypes
ð Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about EOPT
⯠Playground Link
ð» Code
// @strict: true
// @exactOptionalPropertyTypes: true
type A = { a?: number; b: string, z?: {} };
function f(a: A) { return a; }
f({ a: undefined, z: undefined });
// Argument of type '{ a: undefined; }' is not assignable to parameter of type 'A' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
// Property 'b' is missing in type '{ a: undefined; }' but required in type 'A'.(2379)
ð Actual behavior
Normally nested diagnostic messages are a refinement of their parents. In this case the inner diagnostic about property b is not related to the EOPT assignability issue in the head message. We have two different errors being represented in the same chain.
ð Expected behavior
There are several reasonable behaviors here.
- Do not change the parent message to the EOPT flavor when the inner message is not EOPT related
- Report two separate diagnostics
- Display both the current inner message and the EOPT mismatches at the same level
I would prefer option 2.
I have a working version of option 3 that I can a PR for if you want to go that route ( either as a permanent solution or a stop gap until further work on EOPT is done)
Argument of type '{ a: undefined; z: undefined; }' is not assignable to parameter of type 'A'.
Properties not assignable with exactOptionalPropertyTypes: a, z
Property 'b' is missing in type '{ a: undefined; z: undefined; }' but required in type 'A'.ts(2345)
Additional information about the issue
No response