Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Request
A PR to update the type definitions to slightly narrow the number of possible types the stats callback parameters may be.
When a callback is being added to a stats function (usually inline), it's nice to have more specific types for those callback parameters.
Background
I'm a bit of a TypeScript fanatic so I recognize this is a really minor change and I have extra details here that may or may not be necessary!
After reviewing the types.d.ts for all usages of
StatsCb
and then verifying that those functions usingStatsCb
s all ended up using the_send
method of the client, I've come to the conclusion that this is the most accurate type forStatsCb
:However, this is very narrow and most user-written
type
s that try to adhere to the currenttype
would break (see Testing) due to the extra possibility thaterror
could now benull
.My proposed change is:
which makes the
error
parameter clearly optional (?
) and also indicates thatbytes
is optional but that, when it is present, it is always a number.This solution does break one scenario (see Testing,
@ts-expect-error
comment) in which the user has incorrectly typed their own callback function to assume thatbytes
is always present in the call, due to the fact thatany
dissuades TypeScript from further checking its identifier's types.If any breaking change is too much work for this, I would then recommend (and subsequently update the PR) to use this type:
It is the "least different" from the existing
type
but still offers a suggestion as to the type of thebytes
parameter and is able to take advantage of optional parameters.If you've made it this far, thank you!
Testing
I've created this TypeScript Playground with potential scenarios in which users may be utilizing the library based on its current types and then comparing that with the suggested change.
Playground Source (Backup)