Add tracing-web to the list of related crates

[WorldSEnder]

Fixes #2280

Motivation

I've implemented an alternative to tracing-wasm to fix some issues that I had when using it (most are open as longer time bug reports, no need to recount them here). It should be more up to date with the current tracing framework and, being layer based, is easier to compose with other subscribers, e.g. supports formatting and timing on event logs out of the box.

Solution

Add the tracing-web crate to the list of related crates.

[hawkw]

thanks for adding your crate, this is great!

there's also a similar list of related crates in tracing's lib.rs documentation. can you add a link to your crate here as well?

tracing/tracing/src/lib.rs

Lines 770 to 807 in 41337ba

	//! Additionally, there are also several third-party crates which are not
	//! maintained by the `tokio` project. These include:
	//!
	//! - [`tracing-timing`] implements inter-event timing metrics on top of `tracing`.
	//! It provides a subscriber that records the time elapsed between pairs of
	//! `tracing` events and generates histograms.
	//! - [`tracing-opentelemetry`] provides a subscriber for emitting traces to
	//! [OpenTelemetry]-compatible distributed tracing systems.
	//! - [`tracing-honeycomb`] Provides a layer that reports traces spanning multiple machines to [honeycomb.io]. Backed by [`tracing-distributed`].
	//! - [`tracing-distributed`] Provides a generic implementation of a layer that reports traces spanning multiple machines to some backend.
	//! - [`tracing-actix-web`] provides `tracing` integration for the `actix-web` web framework.
	//! - [`tracing-actix`] provides `tracing` integration for the `actix` actor
	//! framework.
	//! - [`tracing-gelf`] implements a subscriber for exporting traces in Greylog
	//! GELF format.
	//! - [`tracing-coz`] provides integration with the [coz] causal profiler
	//! (Linux-only).
	//! - [`tracing-bunyan-formatter`] provides a layer implementation that reports events and spans
	//! in [bunyan] format, enriched with timing information.
	//! - [`tracing-wasm`] provides a `Collect`/`Subscribe` implementation that reports
	//! events and spans via browser `console.log` and [User Timing API (`window.performance`)].
	//! - [`tide-tracing`] provides a [tide] middleware to trace all incoming requests and responses.
	//! - [`test-log`] takes care of initializing `tracing` for tests, based on
	//! environment variables with an `env_logger` compatible syntax.
	//! - [`tracing-unwrap`] provides convenience methods to report failed unwraps
	//! on `Result` or `Option` types to a [`collect`].
	//! - [`diesel-tracing`] provides integration with [`diesel`] database connections.
	//! - [`tracing-tracy`] provides a way to collect [Tracy] profiles in instrumented
	//! applications.
	//! - [`tracing-elastic-apm`] provides a layer for reporting traces to [Elastic APM].
	//! - [`tracing-etw`] provides a layer for emitting Windows [ETW] events.
	//! - [`tracing-fluent-assertions`] provides a fluent assertions-style testing
	//! framework for validating the behavior of `tracing` spans.
	//! - [`sentry-tracing`] provides a layer for reporting events and traces to [Sentry].
	//! - [`tracing-forest`] provides a subscriber that preserves contextual coherence by
	//! grouping together logs from the same spans during writing.
	//! - [`tracing-loki`] provides a layer for shipping logs to [Grafana Loki].
	//! - [`tracing-logfmt`] provides a layer that formats events and spans into the logfmt format.

thanks!

[hawkw]

let's wrap this line at the same column as the other lines in the file?

[WorldSEnder]

I hope I got the line correctly, I didn't find any guidance on the exact number. Is there a rustfmt.toml file somewhere that specifies this?

[hawkw]

thanks, looks good to me! :)