Support `exactOptionalPropertyTypes` (tsc)
connorjs opened this issue · 3 comments
Is your feature request related to a problem? Please describe.
I have a TypeScript project with exactOptionalPropertyTypes: true. When I use graphql-yoga, I get a tsc error because Yoga’s type has url?: string | undefined while NodeRequest (this package) has url?: string.
Describe the solution you'd like
I would like this package to update its optional typing to include | undefined.
Describe alternatives you've considered
- Turn off
exactOptionalPropertyTypes - Use
@ts-ignore - Open the opposite request with graphql yoga (remove the
| undefined)
Additional context
I really like the idea of exactOptionalPropertyTypes, but I have found it hard to adopt given cases such as this one. When I write “library” code with options objects, I usually do foo?: Foo | undefined for compatibility, and reserve the specific ? or | undefined for non-options function inputs (for example: path?: string vs. path: string | undefined) or for my own application code to refactor.
Open to general thoughts on exactOptionalPropertyTypes, including if the existing types without | undefined are better.
If accepted, it seems like an easy PR to do myself.
@ardatan I've made a PR, please review.
I'm currently working on ardatan/feTS#407, enabling exactOptionalPropertyTypes, and I have issues extending types from ServerAdapterOptions, due to plugins being optional, but not | undefined
I'm using fets in my client's project with exactOptionalPropertyTypes enabled, and made had downstream issues with fets, which led me to this repository.
Please review. Would appreciate if you can release new version.
@ardatan please follow up
I just ran into this. A better workaround than using @ts-ignore (which could block other legitimate issues, like forgetting to import createServer) is to as cast the yoga server as a RequestListener (from node:http):
import {RequestListener, createServer} from 'node:http';
const server = createServer(yoga as RequestListener);