Description
An idea would be to add a "strict" mode, which errors when you are violating the types of said endpoint.
It would use a generic in the type definition like following:
function fetch<T>("/api/path", ...);
Which could then, conditionally be enabled in places where it is desired as following:
fetch<Strict>("/api/path");
// This is expected to error with TS2345:
// > Argument of type '"/api/path/which/doesnt/exist"' is not assignable to parameter of type '"/api/path"'.
fetch<Strict>("/api/path/which/doesnt/exist");
// This would also be expected to error if the request init isn't as specified:
// > Type '{ ... }' is missing the following properties from type '{ ... }'
fetch<Strict>("/api/path", { ... });
This would also be entirely opt-in due to the nature of TypeScript and when we can trigger the error without overwriting the base fetch
type.
Flags
I suggest we add two (three?) new flags:
--only-strict
- Enables TypeFetch types only when the strict generic is satisfied, e.g. does not set a generic default. (function fetch<T>
)--optional-strict
- Greedily enables TypeFetch types when the parameters match a specified operation. Strict mode can be enforced by setting the generic but it has a default value so gets matched by default anyways. (function fetch<T = ...>
)- ?
--no-strict
- Disables the strict generic entirely. (function fetch
)
Open to suggestions about how these should be named and described, I am not sure that "strict" is the best way to describe it nor that they should be separate flags. Perhaps a
--strictness=<none|lax|strict>
is better considering the exclusiveness of the option?
PS
I just had a thought: What if we make the type parameter extend the path of the operation. E.g. fetch<T extends `/api/path`>(input: T, ...)
. That way we get strict type checking when it does not have a default set and if the --optional-strict
flag is set it behaves lazily instead.