feat: Add Deno.standalone API (#15996) #18402
Conversation
|
|
There was a problem hiding this comment.
This looks like a reasonable, good API addition, properly tested and all. Nice work!
I'll have to defer to the core team for approval, however. Adding new APIs to the Deno namespace isn't done that lightly. It might be that eg. Deno.build would be a better location for the standalone boolean but I cannot decide that myself.
Thank you for the contribution, and nice work!
|
Cool. Thank you very much. Totally reasonable that this will take time to get approved. I thought about
I'm happy to change this tho, if required :) |
DerZade
force-pushed
the
deno-dot-standalone
branch
from
ed65a28
to
4cdb7f9
Compare
|
This has been open for over two months now. Anything I can do to advance this? I'm happy to fix the merge conflicts and tests, but wanted to wait for at least some comment, whether there is any realistic chance if this getting merged. |
| @@ -4758,6 +4758,13 @@ declare namespace Deno { | |||
| */ | |||
| export const mainModule: string; | |||
|
|
|||
| /** A flag that indicates if the current module is running in a self-contained executable. | |||
| * | |||
| * @tags allow-read | |||
There was a problem hiding this comment.
I think allow-read isn't needed for this data so this tag is unnecessary.
This PR fixes #15996 by attempting to add a new runtime API (
Deno.standalone) to check whether the current code is running inside a self-contained executable.#15996 was my issue from half a year ago and since it got a few thumbs up and I stumbled upon a similar issue just a few days ago and therefore needed such an API for the second time now, I just thought "well, why not implement it myself and see what happens". It would be absolutely understandable if this API were rejected due to lack of demand.
I apologize in advance, for code that is not in the right spot. This is just my first time contributing to Deno and the project is veeeeery huge. 😂 Just let me know what to change 🙃