Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ban "Omit" in favor of "Except" #204

Open
twschiller opened this issue Jan 31, 2024 · 3 comments
Open

Ban "Omit" in favor of "Except" #204

twschiller opened this issue Jan 31, 2024 · 3 comments

Comments

@twschiller
Copy link
Collaborator

twschiller commented Jan 31, 2024

@fregante
Copy link
Collaborator

fregante commented Jan 31, 2024

Probably not a good idea to alter ban-types because eslint doesn’t allow extending existing configuration (rather, it’s possible but you need you import and extend manually) — at least until #36

Should be easier with the no-restricted-syntax rule, but it needs to be added to the extension first.

#186 will take extra work to bring it to the shared config

@fregante
Copy link
Collaborator

fregante commented Feb 19, 2024

By the way, Omit is actually the default for TypeScript. Meaning: You can already pass objects with any number of properties, TypeScript only matches that you have the required ones.

Screenshot 8

TS playground

Omit and Except have different use cases:

  • Omit<{foo: string, bar: string}, 'foo'> is identical to {bar: string}
  • Except<{foo: string, bar: string}, 'foo'> is identical to {bar: string, foo: never}

The latter is not generally needed, every other part of TS already doesn't guarantee that.

@twschiller
Copy link
Collaborator Author

twschiller commented Feb 19, 2024

Interesting, I wasn't aware of that difference in the resulting type (with never). My understanding was that Except enforces you pass property names that exist on the type, so is more resilient to errors due to property name changes

In practice, the resulting type from Except is still more informative at usage sites, because it provides a stronger statement that the property should not be relied on

I don't have a strong preference for how to implement it. I agree that no-restricted-syntax would work for implementing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants