Intl types: Better typing for exactOptionalPropertyTypes needed

[HolgerJeromin]

Bug Report

I did not find a "planning" issue for related issues.
All delivered types should be safe to use with the new Typescript option.

🕗 Version & Regression Information

• I was unable to test this on prior versions because this is a new option

⏯ Playground Link

// @exactOptionalPropertyTypes
const IntlOptions: Intl.DateTimeFormatOptions = {
    timeZone: undefined
};

Workbench Repro

🙁 Actual behavior

Type 'undefined' is not assignable to type 'string'.(2322)

🙂 Expected behavior

Should compile because undefined is a valid property for that object.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat

copied from microsoft/TypeScript-DOM-lib-generator#1126

[orta]

I'm half-half on this, undefined is the default for those values, yes, but it's not documented as something you should really pass in via that MDN page - can you think of a specific reason why we should add this?

[HolgerJeromin]

My real world code is something like that:

let timeZone: string | undefined = getUserTimeZone();
let IntlOptions: Intl.DateTimeFormatOptions = {
     timeZone: timeZone
};

refactoring to

let timeZone: string | undefined = getUserTimeZone();
let IntlOptions: Intl.DateTimeFormatOptions = {};
if (timeZone) {
    IntlOptions.timeZone = timeZone;
}

to make TS happy feels clumsy.
My API returns "use client setting" explicit as undefined (for timezone and locale) to allow direct use in the modern browser APIs.

[orta]

Yeah, that seems reasonable to me

[tolysz]

I would love if the setting of undefined would simply delete the key in the object...i.e. set it to the default of timeZone?

[nmain]

I would love if the setting of undefined would simply delete the key in the object...i.e. set it to the default of timeZone?

Seems like you just want exactOptionalPropertyTypes: false then.

[tolysz]

I would love if the setting of undefined would simply delete the key in the object...i.e. set it to the default of timeZone?

Seems like you just want exactOptionalPropertyTypes: false then.

Is it? I was under the impression that 2 != 3? (But it is more about category then arithmetics)

when: exactOptionalPropertyTypes: false

1. timeZone can be not set
2. timeZone: can be string
3. timeZone can be undefined

exactOptionalPropertyTypes: true

1. timeZone can be not set, but you can not get here back by yourself.
2. timeZone: can be string
   3) timeZone can be undefined

I am asking for a 3rd way: where you can unset the value or it holds value of specific type... so we can still use the ? optional bit on the type but in this stricter way...
We might need some other annotation like it can not be unset maybe a +?

[orta]

Maybe I'm also confused, but point is seems to be what this issue is about. The change would allow all three options by adding | undefined in the .d.ts which you can see in orta@689bf6f

[fatcerberus]

@tolysz

// exactOptionalPropertyTypes: true
foo.optional = undefined;  // error
delete foo.optional;  // all good

[orta]

This is included with #45647 👍🏻