async-compression puts compression codecs behind tokio and futures-io readers and writers

Three crates, one workspace, split by layer

The repository is a Cargo workspace with members = ["crates/*"], and the published versions make the layering visible. compression-core-v0.4.34 and compression-codecs-v0.4.46 were both published on 2026-10-17, and async-compression-v0.4.51 followed on the same day. The names give away the arrangement: a core crate for the traits and shared types, a codecs crate for the algorithm implementations, and the top level crate for the adaptors that plug those codecs into async IO.

The README describes the top level crate in one line: it provides adaptors between compression crates and Rust's modern asynchronous IO types. The workspace Cargo.toml confirms the internal wiring, with compression-core and compression-codecs declared as workspace dependencies pointing at the crates/ directory by path, and pin-project-lite at version 0.2 as the only third-party workspace dependency.

That split is the main design decision. If you want an algorithm without the async layer, or you want to write your own adaptor, you are not forced to take the runtime bindings. The top level crate is a thin skin over the two beneath it, which is the opposite of how a single monolithic crate would be arranged.

The codec list is wider than the runtime abstraction

The algorithm coverage shows up in the build commands the project documents. The wasm32 build line enables a long feature list in one go:

    cargo build --lib --features all-implementations,brotli,bzip2,deflate,gzip,lz4,lzma,xz,zlib,zstd,deflate64 --target wasm32-wasip1-threads

That single command names brotli, bzip2, deflate, gzip, lz4, lzma, xz, zlib, zstd and deflate64, plus the umbrella all-implementations feature. So the supported set covers the common web formats (gzip, deflate, brotli, zstd), the archive formats (bzip2, lzma, xz), the lighter lz4 variant and the deflate64 extension, with each algorithm selectable on its own.

Two feature names in the same commands deserve a note. The project skips all, all-algorithms and all-implementations when it runs its powerset check, which tells you those three are aggregators. And two codec-specific features, xz-parallel and zstdmt, are skipped in a separate place, which suggests parallel or multi threaded variants exist for those two algorithms and are handled outside the ordinary feature matrix.

tokio or futures-io, never both at once

The justfile contains a dedicated recipe for checking the async runtime axis of the feature matrix. The recipe is parameterised by async_runtime, and the comment above it names the two choices: tokio and futures-io. It runs a powerset check against compression-codecs with no dev dependencies, then runs the same kind of check against async-compression with the chosen runtime feature enabled, and finally compiles the crate with the runtime plus the two parallel codec features.

The skip list inside that recipe removes all, all-algorithms, the aggregate implementation feature and the futures-io or tokio variant that is not selected. The pattern of skipping the unselected runtime is the important detail. The two runtimes are alternatives, and the project treats them as mutually exclusive branches of the matrix rather than as features you would enable together.

The workspace lint configuration matches this concern. rust_2018_idioms is set to deny, missing_debug_implementations is set to deny, and unexpected_cfgs is set to warn with an explicit check-cfg for cfg(async_compression_unstable). That last entry is a signal about how the crate gates behaviour that is not yet stable, using a custom cfg rather than a Cargo feature.

The justfile is the build system, and it sets a nightly toolchain

Contributors do not drive this project with plain cargo scripts alone. The repository ships a justfile, and the recipes use a nightly toolchain for formatting and documentation:

export RUSTFLAGS := "--cfg async_compression_unstable"
export RUSTDOCFLAGS := RUSTFLAGS + "--cfg=docsrs -Dwarnings"

Those two exported variables apply to every recipe in the file, which is how the unstable cfg reaches the compiler and how the documentation build gets the docsrs cfg with warnings promoted to errors. The formatting recipe runs just --unstable --fmt and then cargo +nightly fmt, and the check recipe mirrors that with the --check flag, so a nightly toolchain is part of the contributor setup even though the published crates themselves only require a stable one.

The lint recipe compiles the workspace twice, once without default features and once with all of them, which is a cheap way to catch the case where a feature gate changes which code paths compile. The docs recipe uses cargo +nightly doc --workspace --all-features, matching the requirement that documentation is generated with every codec present.

The workspace Cargo.toml sets rust-version = "1.83" and edition = "2018", so downstream users need a recent stable compiler even though contributors work with nightly.

Testing across the feature matrix is the real maintenance cost

The README documents the contributor checks in five numbered groups: fmt, build, nextest, hack check and a wasm32 step marked Linux only. The two that shape the schedule are the powerset check and the wasm32 build.

The powerset check is the expensive one:

    cargo hack check --workspace --feature-powerset --all-targets --skip 'all,all-algorithms,all-implementations'

cargo hack enumerates combinations of features and compiles each one, so the number of build jobs grows with the size of the feature matrix. That is why the aggregators are skipped: enabling all, all-algorithms and all-implementations together produces combinations nobody ships. The justfile goes further with --depth 4 limits on the runtime-specific recipes, which caps how deep the enumeration goes.

The wasm32 step is the other heavy one, and it needs a wasi SDK sysroot downloaded from the WebAssembly/wasi-sdk release, extracted into wasi-sysroot, plus the wasm32-wasip1-threads target installed through rustup. The README marks it Linux only. The CFLAGS_wasm32_wasip1_threads export points the build at that sysroot, which is what lets the native codec dependencies compile for a threaded wasm target.

Where the async boundary stops being the right boundary

This crate exists to bridge two things that do not otherwise meet: codec implementations written against synchronous Read and Write, and the async traits used by tokio and futures-io. If your code is synchronous, the bridge buys you nothing, and the plain codec crates are the shorter path. The adaptors also do not remove the cost of compression itself, since the underlying algorithms still run on the CPU and the async interface only changes how bytes are handed over.

The feature matrix is the second limit. Because each algorithm, each implementation and each runtime is a separate switch, a project that wants zstd on tokio can end up compiling several codec implementations it never calls. The project itself keeps its own aggregate features in check by skipping them in CI, which tells you that the aggregators are convenient for experimentation and awkward as long term settings.

The wasm32 target is the third limit, and it is a hard one rather than a stylistic one. Getting brotli, zstd and xz to build against a wasi SDK sysroot with threads requires the Linux-only steps in the README, so anyone targeting wasm needs the sysroot prepared before the crate will compile for that target at all.

Dual licensed, and moving fast across three crates

The licence arrangement is the permissive one. The README states the project is licensed under either of the Apache License, Version 2.0 or the MIT license, at your option, and the workspace Cargo.toml records license = "MIT OR Apache-2.0". The repository ships LICENSE-APACHE and LICENSE-MIT as separate files. Contributions are dual licensed under the same terms unless a contributor says otherwise, which keeps incoming patches usable under whichever option you prefer. This is a licensing note rather than legal advice.

On maintenance, the three version numbers move in step with the repository. The last push was on 2026-10-17, the repository is not archived, and the three releases published that day (compression-core 0.4.34, compression-codecs 0.4.46, async-compression 0.4.51) show the layers are released together rather than one lagging behind another.

Adopting a workspace means adopting its release cadence, so the practical upgrade path is to watch the version numbers of all three crates and bump them together. The repository uses a release-plz configuration file for that flow, and the CI lives in ci/ with the workflow referenced by the build status badge in the README.

Editorial conclusion

Adopt async-compression when you already build on tokio or futures-io and want gzip, brotli, zstd or xz support in a stream without writing adaptor code per codec. Do not adopt it for a synchronous pipeline, since the point of the crate is the async trait boundary, and be careful with the all-algorithms and all-implementations features because they pull in native codec builds. Verify first which of the three crates you need, compression-core for the traits, compression-codecs for the algorithms and async-compression for the runtime adaptors, then pin a single runtime feature, tokio or futures-io, since the workspace checks feature combinations for both separately.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Nullus157/async-compression on GitHub
3. Project website
4. README
5. Releases