Discussion on `--strictOptionalProperties` #44421

Closed

Discussion on --strictOptionalProperties#44421

Labels

We've pulled in a new feature called --strictOptionalProperties which sits under the --strict family of flags. If we were to start TypeScript over again, we believe the behavior of strictOptionalProperties would be on by default; however, this strictness option comes at a time when the community is much more mature with lots of existing code.

I've opened up this issue to discuss some broader concerns so that we can ensure that --strictOptionalProperties ships smoothly and so we can hear some feedback from users.

Off the bat, here's a few of my own concerns:

Discoverability of the Break

A user who upgrades TypeScript with --strict on currently has no idea why their code has broken. At best, they will get an error like

Type 'T | U | V | undefined' is not assignable to type 'T | U | V'.
  Type 'undefined' is not assignable to type 'T | U | V'.

We can do better here, which is why I've opened up #44403.

Manual Upgrade Woes

The most permissive thing to do to fix breaks from --strictOptionalProperties is to tack on an | undefined onto every single ?-marked optional property; however, this is incredibly tedious for an existing project.

We'd like to provide some automated tooling to help alleviate this, which is why I've opened up #44419.

Surrounding Community Upgrade Woes

There are really 3 places that are outside most users' control that need to be upgraded to work correctly with strictOptionalProperties:

lib.d.ts
DefinitelyTyped (@types packages)
Libraries shipping their own types

The last one is the hardest to solve; however, the first two are way more automatable, and we can have the core team help with it, but it's definitely time taken away from other work, and that's a delicate tradeoff.

I haven't created an issue to manage this one, but I think it might be worth distributing segments of lib.d.ts and some number of top packages to add | undefined to the definitions and see if that helps. Ideally, automation from #44419 could help. We'd also have to update the lib.dom.d.ts generator to emit | undefined on most optional properties.

I'd like to get @RyanCavanaugh's thoughts on this one.

Other Feedback

I'm curious to hear feedback from users on this one - is it a useful option? Do you feel good about it and its purpose? Did it catch any interesting bugs? Let us know!

added

mentioned this in 2 issues

pinned this issue

MemberAuthor

New Errors list from last night #44427 👀

jakebailey

Member

Last night I tried updating pyright/pylance to a build of TS that included this to see how it would go. I'll try and sum up my thoughts...

I'm not sure that this check is going to end up being widely usable any time soon; I get loads of messages coming from the types of libraries I don't control, especially from the LSP client library (and spec), where they treat ? as equivalent to undefined. I think that this pattern is very common and unlikely go away.

As for trying to fix our own code, the messaging is definitely bad; I found it very hard to try and locate the actual place I needed to make the change in a large project. I ended up starting tsc in watch mode, opening a file with an error in VS Code, then I see the problems (as VSC only shows errors in open files). Then, either the related diagnostic pointed back to the declaration (so I could jump and add | undefined), or confusingly did not, in which case I had to go-to-def on the error'd expression to figure out what to change.

I'm sure it could be improved to say something like "property had a ? but no undefined", but that is going to push everyone to add | undefined, in which case, is this check helping?

Before I gave up, I still had hundreds of errors to fix. It seemed almost random which properties I needed to change, and I was left with a number of interfaces where some properties had | undefined and some did not, which tells me that at some point in the future, I may use a property in a new way and have to fix them.

I'm not sure I've actually been able to find any bugs with this so far; maybe I'm too inclined to just try and stick | undefined everywhere. I don't think we do any in checks, and only care about truthiness.

I'm pretty surprised that this is on by default; it feels really noisy (far noisier than the not-default noPropertyAccessFromIndexSignature) and I expect to have to disable it when I upgrade. I think it will be very surprising to users with "strict": true to see this enabled.

glen-84

Is the Required utility type supposed to be removing an explicit undefined?

https://www.typescriptlang.org/play?strictOptionalProperties=true&strict=true&ts=4.4.0-dev.20210602#code/JYOwLgpgTgZghgYwgAgKIA84FsAOAbFAbwChkzk4B+ALmQGcwpQBzZAH2QFcQATCGUBB4BuYgF9ixMAE8cKAILIAvMgAKwBAGsAPBmz4IAGmQAiOCYB8omXOTyASsuT2IAR07AoQ7fKuSEAPYgDMjotA5OhHC03HwCIEJiokA

I thought that it was supposed to just remove the ?.

OoDeLally

I believe language features should be a right balance between exactness and usability, i.e. a health dose of pragmatism.
With this strictOptionalProperties, I feel like we are sacrificing a lot of usability and readability, just for the purpose of exactness.
From my experience there are very little cases (in fact, I've never encountered any) where I care about whether a field is undefined or missing (and if I ever did, there are ways to assert that).

Now, because I use the strict option, I have to clutter all my types with | undefined.

I guess the issue here stems from the fact that there are many levels of strictness, and because strict is binary, the true value means all possible strictness rules. Maybe there could be several levels.

fatcerberus

Maybe there could be several levels.

There are - set the individual flags you need. Multiple strict levels + individual options would just be way too much cognitive overhead IMO. If I'm at the point where I'm asking myself "Which level of strictness do I need?" I should probably be researching what exactly my options are anyway.

fatcerberus

From my experience there are very little cases (in fact, I've never encountered any) where I care about whether a field is undefined or missing (and if I ever did, there are ways to assert that).

Fun fact: When I used to write plain JS, I did "foo" in obj tests all the time. TS forced me out of that habit (very begrudgingly) because it had, until recently, no type-level way to distinguish between ? and | undefined. So while I consider myself pragmatic, I'm hesitant to throw around pragmatism as an excuse here because I never considered the lack of strictOptionalProperties to be very pragmatic 😉

ignatiusmb

mentioned this

on Jun 7, 2021

types: fix misleading Headers type definition sveltejs/kit#1611

Pajn

Fun fact: When I used to write plain JS, I did "foo" in obj tests all the time. TS forced me out of that habit (very begrudgingly) because it had, until recently, no type-level way to distinguish between ? and | undefined.

It does, you can create a type like {foo: string} | {} if you want foo to be optional but not allow undefined as a value so the question is more about final type is more desirable and thus should be represented with the most ergonomic {foo?: string} syntax. Personally I beleave the old way is more common partly because of this statement in the initial post:

We'd also have to update the lib.dom.d.ts generator to emit | undefined on most optional properties.

Which I also believe would be true for most third party libraries as well. If the new strictOptionalProperties behaviour was more common it would have been a widely requested feature up until now. However, now that I know about it I can just add strictOptionalProperties: false to all my tsconfigs so it's not a massive problem. Though if library authors start adding strictOptionalProperties: false they would not catch this and release typings that causes problems for strictOptionalProperties: true so there is a small risk that this causes a lot of churn for both users and library authors.

jcalz

Contributor

It does, you can create a type like {foo: string} | {} if you want foo to be optional but not allow undefined as a value

Playground link

const oops: { foo: string } | {} = { foo: undefined }; // no error

Excess property checks only happen in specific situations, and they never happen for the empty object type {}. There aren't any truly exact types (#12936) so even with excess property checking you could find fun ways to sneak undefined (or even unknown) property values in there.

it would have been a widely requested feature up until now

I guess "widely" is a subjective term, but #13195 does have a decent number of positive reactions, comments, and linked issues.

Pajn

{ foo: string } | { foo: never } then, it's always possible to type it if you actually need it. But I'm not arguing against the existence of this, as I said, I'll just disable it and move on.

26 remaining items

lobsterkatie

Is there any way to add a flag to say, "Not only do I not care about the missing/undefined distinction in my own code, I want consumers of my code to be fine with it, too"? If my code doesn't act any differently based on the missing/undefined distinction, why should it matter which one an exactOptionalPropertyTypes-using app passes me?

@DanielRosenwasser @RyanCavanaugh - Pinging on this. Any chance you'd consider the above?

(Or perhaps I'm wrong about this?

if I don't want to break my users who have this turned on, IIUC I more or less have to turn it on myself, or act like it's turned on, at least, right?

)

RyanCavanaugh

Member

Every strictness flag we've added since day 1 has implied work for upstream maintainers. We assessed the impact of this on DefinitelyTyped and other code bases and felt it was a worthwhile trade-off.

I'm not sure what sort of behavior you're describing with the suggestion. A concrete proposal of what specifically you think could work differently would be a good next step.

lobsterkatie

I'm not sure what sort of behavior you're describing with the suggestion. A concrete proposal of what specifically you think could work differently would be a good next step.

Sorry for not being clear. What I mean is this:

@sentry/browser doesn't make the distinction between missing values and values set to undefined. If we were only building for ourselves, we'd set exactOptionalPropertyTypes to false and continue to just use optional properties in our types, and all would be well.

But my understanding is that if anyone using @sentry/browser has exactOptionalPropertyTypes set to true, and they pass undefined in for some value we've marked as optional, they'll get an error. Currently, the only way for us to help such a user is to add | undefined to all of our optional properties (or at least, any which might conceivably get passed undefined). Correct?

What I'd like is not to have to do that, because IMHO it makes our types cluttered and harder to read, all in order to preserve a distinction our code doesn't make. So I wish there were a setting we could set along the lines of pretendAllOptionalPropertiesInAnyTypesWeExportHaveAnOrUndefinedOnTheEnd. In other words, I'd like to be able to give users of @sentry/browser blanket permission to pass undefined in for any optional property in our types, even if those users have exactOptionalPropertyTypes set to true.

Hopefully that makes more sense. Failing such an option, perhaps there could be a new ?? designation for properties, so that someProp?: string would mean "pass a string or nothing at all" and someProp??: string would mean "pass a string or undefined or nothing at all" (with ?? essentially playing the role ? used to play). Quite frankly I'd take anything which would make this work in a way which doesn't sacrifice so much readability in order to solve a problem which (as far as usage of our SDK is concerned) doesn't exist.

Thanks.

petyosi

mentioned this

on Oct 20, 2022

[BUG] initialTopMostItemIndex={undefined} causes runtime error petyosi/react-virtuoso#777

vbezhenar

Just my 2 cents. I'm starting with typescript and stumbled upon this issue when trying to use this flag.

Here's my simple function:

async function health(signal?: AbortSignal): Promise<void> {
  const response = await fetch(`${backendUrl}/health`, {
    signal,
  });
  const text = await response.text();
  if (!response.ok) {
    throw new Error(
      "Failed to check health: " +
        `${response.status} ${response.statusText}: ${text}`,
    );
  }
}

I didn't find any ergonomic way to implement this code with new flag. Here's one way I've come with but it's ugly:

async function health(signal?: AbortSignal): Promise<void> {
  const response = await fetch(`${backendUrl}/health`, {
    ...(signal !== undefined ? { signal } : {}),
  });
  const text = await response.text();
  if (!response.ok) {
    throw new Error(
      "Failed to check health: " +
        `${response.status} ${response.statusText}: ${text}`,
    );
  }
}

I think there should be a language feature to support this compiler flag to allow for more ergonomic usage.

In this particular case with AbortSignal, there's actually another way: signal: signal ?? null because RequestInit declares signal as signal?: AbortSignal | null;. But I think that API like that is not always available.

That said, I like this flag because it helped me to spot some weird API I designed (like using x?: X instead of x: X | undefined.

RyanCavanaugh

Member

@vbezhenar I don't understand what's wrong with the upper snippet in your comment. It maybe sounds like what you're saying is that you want a way to construct an object literal that conditionally has a property slot?

vbezhenar

@RyanCavanaugh it does not compile with exactOptionalPropertyTypes.

Here's some declarations from lib.dom.d.ts:

declare function fetch(input: RequestInfo | URL, init?: RequestInit): Promise<Response>;

interface RequestInit {
    ...
    signal?: AbortSignal | null;
}

So with exactOptionalPropertyTypes enabled I can't pass undefined to signal.

One work-around is to use second snippet: add property conditionally.

Another work-around is to pass null because this particular API allows to pass null, but not every API allows that.

So, yes, a way to construct object that conditionally has a property slot with more ergonomic syntax would help.

I think someone already suggested syntax like:

fetch(url, { signal?: signal })

Now I understand that TypeScript's philosophy is not to introduce syntax which deviates from JavaScript so I guess it's better to direct that kind of feedback to JavaScript standardization committee.

bodograumann

This has been mentioned above already, but in case you missed it, #39376 is the relevant typescript issue which was rejected and here is the tc39 discussion: https://es.discourse.group/t/optional-property-shorthand-in-object-literal/196

dimitropoulos

mentioned this in 2 pull requests

on Mar 16, 2023

just-boris

mentioned this

on Jul 10, 2023

support exactOptionalPropertyTypes cloudscape-design/documenter#25

phaux

For working with exactOptionalPropertyTypes code base I found this utility function to be super useful:

/**
 * Removes all undefined properties from an object.
 */
export function omitUndef<O extends object | undefined>(object: O):
  & { [K in keyof O as undefined extends O[K] ? never : K]: O[K] }
  & { [K in keyof O as undefined extends O[K] ? K : never]?: O[K] & ({} | null) } 
{
  if (object == undefined) return object as never;
  return Object.fromEntries(
    Object.entries(object).filter(([, v]) => v !== undefined),
  ) as never;
}

MartinJohns

mentioned this

on Feb 22, 2024

TS "Optional Properties" accepts "undefined" as a value when it shouldn't... #57479

RyanCavanaugh

closed this as completed

on Feb 23, 2024

oliviertassinari

mentioned this

on Sep 1, 2024

[data grid] Column definition undefined value mui/mui-x#14446

to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

Labels

DiscussionMeta-Issue

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Discussion on `--strictOptionalProperties` #44421

Discoverability of the Break

Manual Upgrade Woes

Surrounding Community Upgrade Woes

Other Feedback

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Participants

Discussion on --strictOptionalProperties #44421

Description

Discoverability of the Break

Manual Upgrade Woes

Surrounding Community Upgrade Woes

Other Feedback

Activity

DanielRosenwasser commented on Jun 4, 2021

jakebailey commented on Jun 4, 2021

glen-84 commented on Jun 4, 2021

OoDeLally commented on Jun 6, 2021

fatcerberus commented on Jun 6, 2021

fatcerberus commented on Jun 6, 2021

Pajn commented on Jun 7, 2021

jcalz commented on Jun 7, 2021

Pajn commented on Jun 7, 2021

26 remaining items

lobsterkatie commented on Dec 10, 2021

RyanCavanaugh commented on Dec 13, 2021

lobsterkatie commented on Jan 19, 2022

vbezhenar commented on Feb 14, 2023

RyanCavanaugh commented on Feb 14, 2023

vbezhenar commented on Feb 15, 2023

bodograumann commented on Feb 15, 2023

phaux commented on Oct 19, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Participants

Issue actions

Discussion on `--strictOptionalProperties` #44421