std/node should avoid TLA
#2097
Labels
Comments
rivy
added a commit
to rivy/js.os-paths
that referenced
this issue
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 9, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 10, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 10, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 10, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 13, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
Aug 14, 2022
…mpt(s) - revert to earlier deno::std library version without NODE_DEBUG permission prompts # [why] In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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)
|
@nayeemrmn , could this be changed back to a gate using synchronous calls now that synchronous permission functions have been added/merged? It would preserve synchronous import order (and continue to avoid top-level-await [TLA]) but avoid undesired prompt UI when including std modules (see discussion at denoland/deno#13730). Adding a gate with the new sync permission calls could be used to solve #2507. |
|
It's worked here #3132, but now blocked by Deploy compatibility |
rivy
added a commit
to rivy/deno.dxx
that referenced
this issue
Sep 11, 2023
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - downgrade and *pin* to deno/std@0.134.0 - env ... - permissions ... - add no-prompt permission checks - ... # why - ToDO: add further explanation... In the change from deno::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
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 'std@0.134.0' (specifically, 'std@0.97.0'). For the 'std@0.97.0' 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 issue
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 'std@0.134.0' (specifically, 'std@0.97.0'). For the 'std@0.97.0' 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 issue
Oct 29, 2023
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - downgrade and *pin* to deno/std@0.134.0 - 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::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
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 'std@0.134.0' (specifically, 'std@0.97.0'). For the 'std@0.97.0' 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 issue
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 'std@0.134.0' (specifically, 'std@0.97.0'). For the 'std@0.97.0' 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 issue
Nov 5, 2023
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - downgrade and *pin* to deno/std@0.134.0 - 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::std@0.134.0 to deno::std@0.135.0, 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::std@0.135.0+) 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 issue
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 'std@0.134.0' (specifically, 'std@0.97.0'). For the 'std@0.97.0' 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 issue
Nov 20, 2023
- specify import versions per best practice and to avoid Deno warnings - pin to std@0.134.0 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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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
See denoland/deno#14243. Imagine side-effect-importing some polyfill from esm.sh at your application entrypoint. That polyfill was built for Deno to import things from
std/node. If it is asynchronously evaluated, you will get an undesired dependency evaluation order and the conventionalimport "https://cdn.esm.sh/reflect-metadata?deno"at your application entrypoint might not suffice.In this case there is a single easily fixed culprit: https://github.com/denoland/deno_std/blob/8824ae1ef3e53a6531b464f9add1eb40a60b9d64/node/internal/util/debuglog.ts#L108-L113
cc @shivam-tripathi
The text was updated successfully, but these errors were encountered: