-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execution order of imports in deno is unclear/unexpected #14243
Comments
It is intended, this occurs because import "data:application/javascript,import 'https://cdn.esm.sh/reflect-metadata?deno'; console.log(1)";
import "data:application/javascript,console.log(2)"; and observing that The only way to ensure |
Thanks @nayeemrmn, that makes sense. I do however feel that if |
@shivam-tripathi Should be fixed next std release |
…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)
…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)
…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)
…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)
…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)
…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)
…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)
…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)
…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)
- 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)
# [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]:
# [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]:
- 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)
# [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]:
# [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]:
- 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)
# [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]:
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
Is order of imports not guaranteed in deno?
I have a file called main.ts:
And corresponding config.ts
When I run this, I keep running into
I was expecting reflect-metadata to get executed before all other modules (including dependencies imported from remote urls in this case inversify). Is this error expected?
import map:
The text was updated successfully, but these errors were encountered: