bad UX with prompt by default #13730
Assignees
Labels
Comments
|
Similar ugly UI/UX occurs whenever "node/util.ts" is imported. Because of a combination of requirements/decisions, "node/util.ts" can no longer be imported without an undesired prompt, unless $ deno run "https://deno.land/[email protected]/node/util.ts"
⚠️ ️Deno requests env access to "NODE_DEBUG". Run again with --allow-env to bypass this prompt.
Allow? [y/n (y = yes allow, n = no deny)]Choosing allow or deny doesn't make a difference in the success of the import (just later util debug functionality), but this is a UI/UX wart which makes it impossible to present a more user-friendly UI/UX (as opposed to the now default dev-centered UI/UX). Before denoland/std@8b34f73 was merged, a quiet permission query was used, avoiding the prompt. But, because the query was async, it led to unexpected order of execution, with module being imported after other synchronous modules (see denoland/std#2097). And so, the code was changed to a And there's no way that I can find to even test to make sure imported code won't prompt. So, just as the change from '[email protected]' to '[email protected]' unexpectedly added this prompt, any dependency change may add unexpected additional prompts which are confusing to users. A fix would be returning to query-gating all code executed during import which requires permissions. But, to avoid the unexpected order of execution of imported modules, the query-gate would have to be synchronous. |
rivy
added a commit
to rivy/js.os-paths
that referenced
this issue
Aug 9, 2022
- revert to earlier deno::std library version without NODE_DEBUG permission prompts - wip why/refs # [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`. 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). 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 [DENO_NO_PROMPT env var support](denoland/deno#14208) [feat: Add DENO_NO_PROMPT variable](denoland/deno#14209) [discussion: Bring back permission prompt behind a flag](denoland/deno#3811) [Security prompt by default (instead of throw)](denoland/deno#10183) [Bad UX with prompt by default](denoland/deno#13730) [`deno repl` has permissions by default?](denoland/deno#12665) [permission prompt problems](denoland/deno#11936) [Design Meeting 2021-07-29 ~ `Prompt by default`](denoland/deno#11767) [Seeking a better UX for permissions](denoland/deno#11061) [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::[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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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 issue
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)
|
This is not the case anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In 1.19, dynamic imports are prompted even if they are never executed, which causes a bad UX/DX.
For example given something like this:
When running under Deno, the dynamic import will never get executed, but:
Whether permission is granted or denied, the code runs as expected.
With no prompt (and versions prior to 1.19):
The real world usage is in adding support for Node.js for oak, I needed to dynamically import a couple modules if running under Node.js, so they never get loaded under Deno, but if people haven't granted permissions, they get prompted to load
node_shims.tsandhttp_server_node.ts, which is very confusing user experience to say the least.The text was updated successfully, but these errors were encountered: