sindresorhus / tsconfig

Shared TypeScript config for my projects
MIT License
346 stars 29 forks source link

Enable `--exactOptionalPropertyTypes` #14

Open sindresorhus opened 3 years ago

sindresorhus commented 3 years ago

I don't want to do it yet as it will cause some friction. We can try to enable it in 2023.

https://devblogs.microsoft.com/typescript/announcing-typescript-4-4/#exact-optional-property-types

kidonng commented 1 year ago

Almost 3 months into 2023, is it time yet?

fregante commented 1 year ago

I think this will make conditional properties annoying to set:

const a: A = {
    name: 'Fregante',
    email: user.hasEmail ? user.email : undefined
}

Would need to be:

const a: A = {
    name: 'Fregante',
    ...(user.hasEmail ? {email: user.email} : undefined)
}

Or worse yet split with an if.

JavaScript badly needs a new nullish value 🤭

const a: A = {
    name: 'Fregante',
    email: user.hasEmail ? user.email : reallyundefined
}
kidonng commented 1 year ago

TS ESlint has issues with exactOptionalPropertyTypes: https://github.com/typescript-eslint/typescript-eslint/issues/5344

voxpelli commented 1 year ago

@fregante It only makes it annoying to set if the type hasn't been explicitly set to accept undefined, though it makes other cases less annoying, like:

type A = {
  email?: string
}

const foo: A = {
  email: 'foo@example.com'
}

if ('email' in foo && foo.email.length > 1) {
  console.log('This only works with exactOptionalPropertyTypes');
}

When it comes to module development its good to have exactOptionalPropertyTypes on as it will ensure that one specifies types that are not annoying to use with exactOptionalPropertyTypes, though its also dangerous as the above example would throw if someone were to send in an explicit undefined because they lacked exactOptionalPropertyTypes.

I personally have exactOptionalPropertyTypes in all my projects, including my modules.