fix(node): Make global.ts evaluate synchronously #2098
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kt3k
reviewed
Apr 10, 2022
| @@ -86,3 +87,30 @@ Deno.test("clearImmediate is correctly defined", () => { | |||
| assertStrictEquals(globalThis.clearImmediate, timers.clearImmediate); | |||
| assertStrictEquals(window.clearImmediate, timers.clearImmediate); | |||
| }); | |||
|
|
|||
| // https://github.com/denoland/deno_std/issues/2097 | |||
| Deno.test("global.ts evaluates synchronously", async () => { | |||
There was a problem hiding this comment.
Nice test to prevent the regression 👍
kt3k
pushed a commit
to kt3k/deno_std
that referenced
this pull request
Apr 13, 2022
rivy
added a commit
to rivy/js.os-paths
that referenced
this pull request
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.os-paths
that referenced
this pull request
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.os-paths
that referenced
this pull request
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.xdg-portable
that referenced
this pull request
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.xdg-app-paths
that referenced
this pull request
Aug 10, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.xdg-app-paths
that referenced
this pull request
Aug 10, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.xdg-app-paths
that referenced
this pull request
Aug 10, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.xdg-app-paths
that referenced
this pull request
Aug 13, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/js.xdg-app-paths
that referenced
this pull request
Aug 14, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just "downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Seeking a better UX for permissions](denoland/deno#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [permission prompt problems](denoland/deno#11936) [`deno repl` has permissions by default?](denoland/deno#12665) [Bad UX with prompt by default](denoland/deno#13730) [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno#15356)
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Sep 11, 2023
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - downgrade and *pin* to deno/[email protected] - env ... - permissions ... - add no-prompt permission checks - ... # why - ToDO: add further explanation... In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which try to control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356)
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Oct 10, 2023
# [notes] For reasons of UI/UX, `bmp` version '0.0.7' is recommended as it is the latest version which uses a version of the std library equal to or earlier than '[email protected]' (specifically, '[email protected]'). For the '[email protected]' library, the corresponding minimally required version of Deno is '1.11.0'. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356)[1]:
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Oct 11, 2023
# [notes] For reasons of UI/UX, `bmp` version '0.0.7' is recommended as it is the latest version which uses a version of the std library equal to or earlier than '[email protected]' (specifically, '[email protected]'). For the '[email protected]' library, the corresponding minimally required version of Deno is '1.11.0'. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356)[1]:
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Oct 29, 2023
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - downgrade and *pin* to deno/[email protected] - permissions - add no-prompt permission query gates with a controlled UI to avoid panics/prompts - env - add guarded environment variable access based on permission gates - automated testing to verify *no-panic* and *no-prompt* is unfortunately a work-in-progress (see [4]) # why In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which otherwise control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) [4] [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Oct 29, 2023
# [notes] For reasons of UI/UX, `bmp` version '0.0.7' is recommended as it is the latest version which uses a version of the std library equal to or earlier than '[email protected]' (specifically, '[email protected]'). For the '[email protected]' library, the corresponding minimally required version of Deno is '1.11.0'. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356)[1]:
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Oct 29, 2023
# [notes] For reasons of UI/UX, `bmp` version '0.0.7' is recommended as it is the latest version which uses a version of the std library equal to or earlier than '[email protected]' (specifically, '[email protected]'). For the '[email protected]' library, the corresponding minimally required version of Deno is '1.11.0'. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356)[1]:
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Nov 5, 2023
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - downgrade and *pin* to deno/[email protected] - permissions - add no-prompt permission query gates with a controlled UI to avoid panics/prompts - env - add guarded environment variable access based on permission gates - automated testing to verify *no-panic* and *no-prompt* is unfortunately a work-in-progress (see [4]) # why In the change from deno::[email protected] to deno::[email protected], a change was made to remove a top-level async permission query gate from the library, replacing it with a synchronous `try...catch`.[1] This was done to avoid unexpected module load order since the module with `await` will run at a time later than synchronous peers (although still prior to user code).[2,3] Unfortunately, the, now default, behavior of Deno is to prompt on use for permissions which aren't 'granted' or 'denied'. This leads to ugly UI/UX for scripts which otherwise control their logging and UI (as well as being confusing and unexpected for non-developer users). This UI/UX behavior is only avoidable if the script is run with the `--no-prompt` option flag or all needed permissions enabled, encouraging use of `--no-prompt` and, more problematically, `--allow-all`. As of 2022-08, with the current Deno (Deno v1.8.0+) and deno::std (deno::[email protected]+) library implementation, no work-around is possible due to: 1. being impossible to actually revoke a permission (`revoke` just downgrade[s] a permission from 'granted' to 'prompt'); 2. the permission API has no synchronous functions making revocation impossible prior to a synchronous access (even if a polyfill patch via module was attempted). Reversion and pinning of deno::std to v0.134.0 avoids the patch changing from async gating to sync `try...catch` while still maintaining most of the functionality of later deno::std library versions. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) [4] [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy/deno.dxx
that referenced
this pull request
Nov 5, 2023
# [notes] For reasons of UI/UX, `bmp` version '0.0.7' is recommended as it is the latest version which uses a version of the std library equal to or earlier than '[email protected]' (specifically, '[email protected]'). For the '[email protected]' library, the corresponding minimally required version of Deno is '1.11.0'. # refs [1] [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [2] [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [3] [std/node should avoid TLA](denoland/std#2097) ## related discussion/issues [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356)[1]:
rivy
added a commit
to rivy-fix/escalade
that referenced
this pull request
Nov 20, 2023
- specify import versions per best practice and to avoid Deno warnings - pin to [email protected] to avoid Deno prompts # refs - ref: [fix(deno): specify import versions (avoids Deno warnings)](lukeed#8) - closed as dead after being ghosted by @lukeed - ref: [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217) ## related discussion/issues [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy-fix/yargs-parser
that referenced
this pull request
Nov 20, 2023
- best practice and strongly needed b/c Deno does *not* use semantic versioning - avoids Deno warnings - also avoids Deno prompts # refs - [fix(deno): specify deps (avoids Deno warnings)](yargs#464) - closed for non-participation at 1 yr open - [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217 (comment)) ## related discussion/issues [refactor ~ implement *no-panic*/*no-prompt* changes](rivy/deno.dxx@a53375d) @@ <https://archive.is/Esp5e> [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy-fix/yargs-parser
that referenced
this pull request
Nov 20, 2023
- best practice and strongly needed b/c Deno does *not* use semantic versioning - avoids Deno warnings - also avoids Deno prompts # refs - [fix(deno): specify deps (avoids Deno warnings)](yargs#464) - closed for non-participation at 1 yr open - [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217 (comment)) ## related discussion/issues [refactor ~ implement *no-panic*/*no-prompt* changes](rivy/deno.dxx@a53375d) @@ <https://archive.is/Esp5e> [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy-fix/yargs-parser
that referenced
this pull request
Nov 20, 2023
- best practice and strongly needed b/c Deno does *not* use semantic versioning - avoids Deno warnings - also avoids Deno prompts # refs - [fix(deno): specify deps (avoids Deno warnings)](yargs#464) - closed for non-participation at 1 yr open - [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217 (comment)) ## related discussion/issues [refactor ~ implement *no-panic*/*no-prompt* changes](rivy/deno.dxx@a53375d) @@ <https://archive.is/Esp5e> [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy-fix/yargs-parser
that referenced
this pull request
Nov 21, 2023
- best practice and strongly needed b/c Deno does *not* use semantic versioning - avoids Deno warnings - also avoids Deno prompts # refs - [fix(deno): specify deps (avoids Deno warnings)](yargs#464) - closed for non-participation at 1 yr open - [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217 (comment)) ## related discussion/issues [refactor ~ implement *no-panic*/*no-prompt* changes](rivy/deno.dxx@a53375d) @@ <https://archive.is/Esp5e> [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy-fix/yargs-parser
that referenced
this pull request
Nov 21, 2023
- best practice and strongly needed b/c Deno does *not* use semantic versioning - avoids Deno warnings - also avoids Deno prompts # refs - [fix(deno): specify deps (avoids Deno warnings)](yargs#464) - closed for non-participation at 1 yr open - [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217 (comment)) ## related discussion/issues [refactor ~ implement *no-panic*/*no-prompt* changes](rivy/deno.dxx@a53375d) @@ <https://archive.is/Esp5e> [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
rivy
added a commit
to rivy-fix/yargs-parser
that referenced
this pull request
Nov 21, 2023
- best practice and strongly needed b/c Deno does *not* use semantic versioning - avoids Deno warnings - also avoids Deno prompts # refs - [fix(deno): specify deps (avoids Deno warnings)](yargs#464) - closed for non-participation at 1 yr open - [fix(deno): refactor to avoid prompts during module import](yargs/yargs#2217 (comment)) ## related discussion/issues [refactor ~ implement *no-panic*/*no-prompt* changes](rivy/deno.dxx@a53375d) @@ <https://archive.is/Esp5e> [fix(node): Make global.ts evaluate synchronously](denoland/std#2098) [Execution order of imports in deno is unclear/unexpected](denoland/deno#14243) [std/node should avoid TLA](denoland/std#2097) [HowTO test that a module is *no-panic* and *no-prompt* when statically imported?](denoland/deno/issues/#15356) [Discussion ~ Bring back permission prompt behind a flag](denoland/deno/issues/#3811) [Security prompt by default (instead of throw)](denoland/deno/issues/#10183) [Seeking a better UX for permissions](denoland/deno/issues/#11061) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno/issues/#11767) [permission prompt problems](denoland/deno/issues/#11936) [`deno repl` has permissions by default?](denoland/deno/issues/#12665) [Bad UX with prompt by default](denoland/deno/issues/#13730) [DENO_NO_PROMPT env var support](denoland/deno/issues/#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno/issues/#14209)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2097.