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

feat(runtime): make kill signal optional #16299

Merged
merged 4 commits into from
Oct 26, 2022

Conversation

crowlKats
Copy link
Member

No description provided.

@@ -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"`.
Copy link
Member

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

https://jsdoc.app/tags-param.html

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

@crowlKats crowlKats Oct 16, 2022

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...

@bartlomieju
Copy link
Member

This is effectively a breaking change to a stable API. What's the reason for it?

@crowlKats
Copy link
Member Author

I dont think its breaking, as it adds an additional possibility of value being undefined, so any old code should still be working.
This came up as a discussion wednesday night

@bartlomieju bartlomieju added this to the 1.27 milestone Oct 22, 2022
Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

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

LGTM

@bartlomieju bartlomieju merged commit 6ac603e into denoland:main Oct 26, 2022
@crowlKats crowlKats deleted the default_kill_signal branch November 20, 2022 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants