Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typings: add JSDoc typings for timers #38834

Closed
wants to merge 2 commits into from

Conversation

VoltrexKeyva
Copy link
Member

Added JSDoc typings for the timers lib module.

Added JSDoc typings for the `timers` lib module.
@github-actions github-actions bot added needs-ci PRs that need a full CI run. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. labels May 28, 2021
@VoltrexKeyva
Copy link
Member Author

VoltrexKeyva commented May 28, 2021

On a note, the setTimeout(), setInterval() and setImmediate() functions take rest parameters at the end to pass to the given callback which are defined as arg1, arg2, arg3, but as it takes more parameters than that with the usage of the arguments object and a for loop, we can't make JSDoc typings tell the user that the function takes more parameters than just 3 without the usage of the spread operator (...) to point out rest parameters (e.g. ...args) in the function parameters itself, could we do anything about this?

jasnell
jasnell previously approved these changes May 28, 2021
@jasnell jasnell dismissed their stale review May 28, 2021 20:55

Hit the wrong button

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple of small clarifications but the rest looks good.

lib/timers.js Outdated Show resolved Hide resolved
lib/timers.js Outdated Show resolved Hide resolved
@apapirovski
Copy link
Member

apapirovski commented Jun 11, 2021

On a note, the setTimeout(), setInterval() and setImmediate() functions take rest parameters at the end to pass to the given callback which are defined as arg1, arg2, arg3, but as it takes more parameters than that with the usage of the arguments object and a for loop, we can't make JSDoc typings tell the user that the function takes more parameters than just 3 without the usage of the spread operator (...) to point out rest parameters (e.g. ...args) in the function parameters itself, could we do anything about this?

Spread operator was slower than what we have, last time I tried it, but you could always make that change locally and see how the benchmarks perform with it.

Other than that, I'm not super familiar with JSDoc intricacies but I assume that replacing arg1, arg2, arg3 with ...args is not something it'll take to well since the code doesn't match? (Or if it doesn't enforce it then I would say that just representing the intention of the function rather than how it's coded is probably more important.)

Fixed parameter type of `clearTimeout()` and `clearInterval()`.
@VoltrexKeyva
Copy link
Member Author

On a note, the setTimeout(), setInterval() and setImmediate() functions take rest parameters at the end to pass to the given callback which are defined as arg1, arg2, arg3, but as it takes more parameters than that with the usage of the arguments object and a for loop, we can't make JSDoc typings tell the user that the function takes more parameters than just 3 without the usage of the spread operator (...) to point out rest parameters (e.g. ...args) in the function parameters itself, could we do anything about this?

Spread operator was slower than what we have, last time I tried it, but you could always make that change locally and see how the benchmarks perform with it.

Other than that, I'm not super familiar with JSDoc intricacies but I assume that replacing arg1, arg2, arg3 with ...args is not something it'll take to well since the code doesn't match? (Or if it doesn't enforce it then I would say that just representing the intention of the function rather than how it's coded is probably more important.)

yea, JSDoc does not enforce typings if the code does not match; so the only of doing this is replacing those 3 parameters at the end with a rest parameter but that may cause a perf regression, so I think we should just let it either be this way as it is, or maybe change the parameter to a rest one and benchmarking them, overall the intension of the function is the most important.

@apapirovski
Copy link
Member

so I think we should just let it either be this way as it is, or maybe change the parameter to a rest one and benchmarking them

Would definitely encourage trying this locally. I don't know if it's been tried in over a year at this point so the performance could've easily gotten on par. If you prefer not to run them locally, can always open a PR and run the benchmarks in CI.

@apapirovski
Copy link
Member

@VoltrexMaster so looking at JSDoc documentation, it seems like we could actually get away with https://jsdoc.app/tags-param.html#multiple-types-and-repeatable-parameters where you specify arg3 as being repeated. It's a bit ugly but at least gets information across? So it seems like you could do

/**
 * Schedules the immediate execution of `callback`
 * after I/O events' callbacks.
 * @param {Function} callback
 * @param {any} [arg1]
 * @param {any} [arg2]
 * @param {...*} [arg3]
 * @returns {Immediate}
 */

@VoltrexKeyva
Copy link
Member Author

@apapirovski sadly that doesn't work, stays the same type as any as a single parameter, the code must match for it to work.

@apapirovski
Copy link
Member

Interesting. The documentation calls this out as the solution to using arguments in your code... wonder if regression, outdated documentation, or if it only works with a single param function?

@VoltrexKeyva
Copy link
Member Author

Interesting. The documentation calls this out as the solution to using arguments in your code... wonder if regression, outdated documentation, or if it only works with a single param function?

Imma just let it stay like this, I may try to benchmark the functions after applying rest parameters in the future and open a PR to make the changes if a perf regression doesn't happen.

@aduh95 aduh95 added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jun 16, 2021
targos pushed a commit that referenced this pull request Jul 11, 2021
Added JSDoc typings for the `timers` lib module.

PR-URL: #38834
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
@targos
Copy link
Member

targos commented Jul 11, 2021

Landed in c4096a3

@targos targos closed this Jul 11, 2021
targos pushed a commit that referenced this pull request Jul 11, 2021
Added JSDoc typings for the `timers` lib module.

PR-URL: #38834
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
targos pushed a commit that referenced this pull request Sep 4, 2021
Added JSDoc typings for the `timers` lib module.

PR-URL: #38834
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. needs-ci PRs that need a full CI run. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. typings
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants