Closed Retro64 closed 1 year ago
This feels kind of stage. @Retro64 is this a common practice ? Doesn't anyone with a good TS experience could validate ?
Minimum example, why this might be dangerous:
import * as HttpStatus from 'http-status';
const foo = (bar: string) =>
console.log(bar.toLowerCase);
const test = HttpStatus[777];
foo(test);
Compiles properly, as test is typed as string, fails at runtime, as test is no string. Indicating it might be undefined leads to a warning it might not be defined during compile time.
OK, I get it, thank you. Please prepare a PR.
The library returns undefined for unknown status codes, which is not reflected in the types.
So I guess this would be a rather correct type:
For convenience - as the lib might quite often be used to trace foreign messages, where you might not rely on correct content - the types might even be extended (last lines to give concrete values priority) with:readonly [key: undefined]: undefinedorreadonly [key: unknown]: undefinedBut these are really optional and opinionated.I might provide a PR with the fix
and/or the feature, if it is accepted