foster/denoland-deno
0
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2025-02-19 11:52:52 -05:00
Code Issues Packages 1 Wiki Activity
denoland-deno/runtime/permissions/Cargo.toml

32 lines
923 B
TOML
Raw Normal View History

chore: Happy New Year 2025 (#27509)
2025-01-01 04:12:39 +09:00
# Copyright 2018-2025 the Deno authors. MIT license.
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
[package]
name = "deno_permissions"
chore: release "deno_*" crates (#27402) Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com> Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-12-17 11:03:58 -05:00
version = "0.43.0"
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
authors.workspace = true
edition.workspace = true
license.workspace = true
repository.workspace = true
description = "Provides the deno permissions implementation."
[lib]
name = "deno_permissions"
path = "lib.rs"
[dependencies]
chore: reduce allocations in a few places (#27288) Probably doesn't have much impact. I didn't measure any of these, but reducing allocations should always be good.
2024-12-09 19:28:53 -05:00
capacity_builder.workspace = true
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
deno_core.workspace = true
refactor: use deno_path_util (#25918)
2024-09-28 07:55:01 -04:00
deno_path_util.workspace = true
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
deno_terminal.workspace = true
fix(runtime): use FQDN in NetDescriptor (#23084)
2024-03-26 23:27:40 +00:00
fqdn = "0.3.4"
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
libc.workspace = true
log.workspace = true
once_cell.workspace = true
fix: do not panic running invalid file specifier (#25530) Co-authored-by: Bedis Nbiba <bedisnbiba@gmail.com>
2024-09-18 16:51:39 +03:00
percent-encoding = { version = "2.3.1", features = [] }
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
serde.workspace = true
refactor(runtime/permissions): use concrete error types (#26464)
2024-11-04 09:17:21 -08:00
thiserror.workspace = true
feat(node): Support executing npm package lifecycle scripts (preinstall/install/postinstall) (#24487) Adds support for running npm package lifecycle scripts, opted into via a new `--allow-scripts` flag. With this PR, when running `deno cache` (or `DENO_FUTURE=1 deno install`) you can specify the `--allow-scripts=pkg1,pkg2` flag to run lifecycle scripts attached to the given packages. Note at the moment this only works when `nodeModulesDir` is true (using the local resolver). When a package with un-run lifecycle scripts is encountered, we emit a warning suggesting things may not work and to try running lifecycle scripts. Additionally, if a package script implicitly requires `node-gyp` and it's not found on the system, we emit a warning. Extra things in this PR: - Extracted out bits of `task.rs` into a separate module for reuse - Added a couple fields to `process.config` in order to support `node-gyp` (it relies on a few variables being there) - Drive by fix to downloading new npm packages to test registry --- TODO: - [x] validation for allow-scripts args (make sure it looks like an npm package) - [x] make allow-scripts matching smarter - [ ] figure out what issues this closes --- Review notes: - This adds a bunch of deps to our test registry due to using `node-gyp`, so it's pretty noisy
2024-07-09 20:06:08 -07:00
which.workspace = true
refactor: add `deno_permissions` crate (#22236) Issue https://github.com/denoland/deno/issues/22222 ![image](https://github.com/denoland/deno/assets/34997667/2af8474b-b919-4519-98ce-9d29bc7829f2) This PR moves `runtime/permissions` code to a upstream crate called `deno_permissions`. The `deno_permissions::PermissionsContainer` is put into the OpState and can be used instead of the current trait-based permissions system. For this PR, I've migrated `deno_fetch` to the new crate but kept the rest of the trait-based system as a wrapper of `deno_permissions` crate. Doing the migration all at once is error prone and hard to review. Comparing incremental compile times for `ext/fetch` on Mac M1: | profile | `cargo build --bin deno` | `cargo plonk build --bin deno` | | --------- | ------------- | ------------------- | | `debug` | 20 s | 0.8s | | `release` | 4 mins 12 s | 1.4s |
2024-03-12 10:42:26 -07:00
[target.'cfg(windows)'.dependencies]
fix(ext/permissions): add correct feature flags to winapi (#24218)
2024-06-17 01:29:16 -04:00
winapi = { workspace = true, features = ["commapi", "knownfolders", "mswsock", "objbase", "psapi", "shlobj", "tlhelp32", "winbase", "winerror", "winuser", "winsock2", "processenv", "wincon", "wincontypes"] }
Copy permalink