-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
feat(runtime): make kill signal optional #16299
Conversation
@@ -3394,18 +3394,19 @@ declare namespace Deno { | |||
/** Clean up resources associated with the sub-process instance. */ | |||
close(): void; | |||
/** Send a signal to process. | |||
* Default signal is `"SIGTERM"`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the intellisense/generated documentation is better if we do something like the following?
* @param [signo="SIGTERM"] - Signal to send to the process
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh interesting, didnt notice thats a thing. quickly checked, and deno_doc doesn't support it, so going to look into adding that first
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should wait for microsoft/tsdoc#151 actually. Just noticed that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, looking at that issue, made me notice microsoft/tsdoc#27, which we actually recently implemented... so maybe it would be fine? because i am in the need for default value for parameters for various documentation related things, so ideally we would implement it as per jsdoc spec. because i honestly have little hope that those tsdoc issues will get resolved anytime soon and being blocked on those for a massive improvement in documentation would just be silly...
This is effectively a breaking change to a stable API. What's the reason for it? |
I dont think its breaking, as it adds an additional possibility of value being undefined, so any old code should still be working. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
No description provided.