Skip to content

Add option to throw error when ! (NonNull expression) is used on a non-nullish expressionΒ #58072

Open
@Ayc0

Description

@Ayc0

πŸ” Search Terms

"cast", "non null", "nonnull", "@ts-expect-error", "strict", "error"

βœ… Viability Checklist

⭐ Suggestion

Add in the TSConfig.json a way to tell TS to check when devs are using ! (non null expressions) on variables that are non null

πŸ“ƒ Motivating Example

Mimic @ts-ignore vs @ts-expect-error but for !:
In well maintained codebases, @ts-expect-error can be preferred to @ts-ignore to get rid of those as soon as they become non necessary.
A similar thinking could be applied to ! so that we can keep healthy codebases

πŸ’» Use Cases

  1. What do you want to use this for?

Seeing ! in a codebase should mean that the variable can be nullish, and that we're telling TS that it isn't in practice.
It replicates @ts-expect-error but for !, at one difference: when using @ts-expect-error you can pick if you want this or @ts-ignore. With this proposal, it'd be set in the TSConfig so would get applied to all ! (but this is I think what devs would want)

  1. What shortcomings exist with current approaches?

In large codebases, we can't keep track of why a ! was used, and whether it's still required. So we need to come back to them, and remove them manually to see if TS is happy or not without them. We can use ESLint to warn us against the use of ! but it's a 100% process.

  1. What workarounds are you using in the meantime?

TypeScript-ESLint can be used to either warn / ban ! and instead push devs to use ?. or ??, but sometimes a variable is indeed never nullish, so it modifies / slows down the runtime for no real reason.

As TypeScript-ESLint can also have access to the full TS process, we could also use it to check the type of the variable on which ! is used to see if it's necessary. But this requires spawning the full TS process in ESLint, slowing it down significantly on large codebases (which is why having it directly in TS could be better)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions