Use Record<string, never> instead of {} for empty types
See original GitHub issueIs your feature request related to a problem? Please describe. By default the typescript resolver plugin creates typing information of the form
export type Resolver<TResult, TParent = {}, TContext = {}, TArgs = {}> = ...
export type ResolversParentTypes = ResolversObject<{
Mutation: {};
Query: {};
}
The expectation here is that {}
denotes the empty type (which only accepts the empty variable {}
). However, this is not the case:
interface AAA {
aaa: {};
}
const x: AAA = { aaa: true };
compiles just fine. Indeed, the type {}
stands for any non-nullish value. For more details and examples see https://github.com/typescript-eslint/typescript-eslint/issues/2063#issuecomment-675156492.
Describe the solution you’d like
Using Record<string, never>
instead of {}
at least for parents and args (not sure about the default context).
Describe alternatives you’ve considered
Additional context
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:8 (1 by maintainers)
Top Results From Across the Web
Intersection type with Record<string, never> does not allow ...
Record <string, never> is an empty object in the sense that you can't add any string-type accessor properties to it (again, unless you...
Read more >Empty object type is not working · Issue #47486 - GitHub
Record <string, never> doesn't actually represent an empty object, but rather an object where every property is type never . As never is...
Read more >Haz on Twitter: "Is this a correct way to declare an empty ...
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead. 1.
Read more >When to use `never` and `unknown` in TypeScript
never is the empty set. There is no value that can be assigned to variable of type never . In fact, it is...
Read more >The difference between {}, object and Record<string, unknown ...
You should add Record<never, never> for the fully empty object, ... I said "Why use TypeScript if you ignore the type system" and...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@fivethreeo the provided test is actually passing with
{}
.While I agree with the design idea from @tobiasdiez, the current implementation is working properly and does not introduce unwanted behaviors.
Hi @tobiasdiez and thank you for the report!
Sorry but I’m not adding a lot here but just labeling it according to our new Contribution Guide and issue flow.
It seems already got into
stage 0
.Now in order to advance to
stage 1
we’ll need a simple reproduction, maybe in code-sandbox?Later to progress to
stage 2
, a failing test would be needed, would be great if someone could help progress the issues through the stages.Thank you and sorry that this comment is not a complete solution (yet).