Some functions are erroneously listed as returning `undefined`
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 64
- Forks
- 71
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 31
Description
URL:
https://beta.docs.nodejs.org/net.html#blocklistisblocklistvalue
Browser Name:
Firefox, Chrome
Browser Version:
153.0
Operating System:
macOS 15.7.8
How to reproduce the issue:
The new return type annotations are incorrect if a function has a non-standard description of its return value. An illustrative example is BlockList.isBlockList, which incorrectly shows undefined:
A non-exhaustive list of other examples I've found:
- https://beta.docs.nodejs.org/net.html#new-netsocketaddressoptions shows a return type of
voidfrom the constructor - https://beta.docs.nodejs.org/net.html#blocklisttojson
- https://beta.docs.nodejs.org/net.html#socketaddressparseinput (does not list
undefinedas a possible return) - https://beta.docs.nodejs.org/net.html#new-netboundsocketoptions shows a return type of
voidfrom the constructor - https://beta.docs.nodejs.org/buffer.html#new-bufferblobsources-options shows a return type of
voidfrom the constructor - https://beta.docs.nodejs.org/buffer.html#blobbytes
- https://beta.docs.nodejs.org/buffer.html#blobslicestart-end-type
- https://beta.docs.nodejs.org/buffer.html#new-bufferarray (and related constructors)
- https://beta.docs.nodejs.org/buffer.html#new-bufferfilesources-filename-options
- https://beta.docs.nodejs.org/buffer.html#bufferatobdata
- https://beta.docs.nodejs.org/buffer.html#bufferbtoadata
- https://beta.docs.nodejs.org/fs.html#filehandlesymbolasyncdispose should return a
Promise, notvoid - https://beta.docs.nodejs.org/fs.html#dirsymbolasyncdispose also should return a
Promise - https://beta.docs.nodejs.org/fs.html#new-fsutf8streamoptions
- https://beta.docs.nodejs.org/http.html#new-agentoptions
- https://beta.docs.nodejs.org/http.html#httpgetoptions-callback this should return the same type as the alternative overload beneath it (i.e.
http.ClientRequest) - https://beta.docs.nodejs.org/http.html#httprequestoptions-callback also should return
http.ClientRequest - https://beta.docs.nodejs.org/sqlite.html#new-databasesyncpath-options
- https://beta.docs.nodejs.org/url.html#new-urlinput-base
- https://beta.docs.nodejs.org/url.html#new-urlpattern (and variants)
- https://beta.docs.nodejs.org/url.html#urlpatterntestinput-baseurl should return
boolean - https://beta.docs.nodejs.org/url.html#new-urlsearchparams (and variants)
- https://beta.docs.nodejs.org/url.html#urlformaturlobject (should return a
string)
Brian edit: converted these to list items for tracking
Presumably these are issues with the source data, which should be made consistent. But previously the documentation "got away" with it because it didn't try to show this normalised value. In the new documentation, it is probably better to err towards not showing the type in cases where it is not clear, to avoid confusion from mismatches.
Common themes are:
- constructors shown as returning
void - async dispose methods shown as returning
voidinstead ofPromise, as required by the interface - functions with non-standard return text shown as returning
undefined - occasionally functions with multiple possible return types only showing the first option
- some functions which have annotated their return type in the comments instead of in a structured way
- overloaded functions only setting a return type on the last overload
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Begin by comparing the return types shown on the linked net, buffer, fs, http, sqlite, and url documentation pages with their source descriptions. Trace how doc-kit normalizes return information, especially constructors, overloads, async disposal methods, and non-standard descriptions. Done means the listed examples show accurate types or omit them when the source is ambiguous.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- documentation, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100