1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-22 15:06:54 -05:00
denoland-deno/ext/tls/Cargo.toml

26 lines
620 B
TOML
Raw Normal View History

# Copyright 2018-2024 the Deno authors. All rights reserved. MIT license.
[package]
name = "deno_tls"
version = "0.132.0"
2022-11-22 15:07:35 -05:00
authors.workspace = true
edition.workspace = true
license.workspace = true
readme = "README.md"
2022-11-22 15:07:35 -05:00
repository.workspace = true
description = "TLS for Deno"
[lib]
path = "lib.rs"
[dependencies]
2022-11-22 15:07:35 -05:00
deno_core.workspace = true
deno_native_certs = "0.2.0"
2022-11-22 15:07:35 -05:00
once_cell.workspace = true
rustls = { workspace = true, features = ["dangerous_configuration"] }
rustls-pemfile.workspace = true
refactor: split integration tests from CLI (part 1) (#22308) This PR separates integration tests from CLI tests into a new project named `cli_tests`. This is a prerequisite for an integration test runner that can work with either the CLI binary in the current project, or one that is built ahead of time. ## Background Rust does not have the concept of artifact dependencies yet (https://github.com/rust-lang/cargo/issues/9096). Because of this, the only way we can ensure a binary is built before running associated tests is by hanging tests off the crate with the binary itself. Unfortunately this means that to run those tests, you _must_ build the binary and in the case of the deno executable that might be a 10 minute wait in release mode. ## Implementation To allow for tests to run with and without the requirement that the binary is up-to-date, we split the integration tests into a project of their own. As these tests would not require the binary to build itself before being run as-is, we add a stub integration `[[test]]` target in the `cli` project that invokes these tests using `cargo test`. The stub test runner we add has `harness = false` so that we can get access to a `main` function. This `main` function's sole job is to `execvp` the command `cargo test -p deno_cli`, effectively "calling" another cargo target. This ensures that the deno executable is always correctly rebuilt before running the stub test runner from `cli`, and gets us closer to be able to run the entire integration test suite on arbitrary deno executables (and therefore split the build into multiple phases). The new `cli_tests` project lives within `cli` to avoid a large PR. In later PRs, the test data will be split from the `cli` project. As there are a few thousand files, it'll be better to do this as a completely separate PR to avoid noise.
2024-02-09 15:33:05 -05:00
rustls-tokio-stream.workspace = true
rustls-webpki.workspace = true
2022-11-22 15:07:35 -05:00
serde.workspace = true
webpki-roots.workspace = true