jyn

> I would be glad to know there is a more direct way to support these ecosystem types vs. conversion traits! I think we could make these available using https://docs.rs/http/0.2.4/http/struct.Extensions.html....

We could make it less verbose by adding an extension trait: ```rust use worker::RequestExt; req.cf().minify.javascript = true; ``` which just calls `extensions_mut().get_mut().unwrap()` under the hood.

> It's probably desirable to support an environment variable, e.g. RUST_LOG_COLOR Rustc does this with an environment variable, RUSTC_LOG_COLOR. I would prefer not to do this in tracing itself so...

I would rather not do this. RUSTFLAGS are global and are often set by .cargo/config; I don't know of a way to merge .cargo/config with a process-local variable. They're also...

@hawkw I think @davidbarsky meant that if we use a *new* env variable read by a build script, it will still be a significant fraction of crates because tracing is...

> > if nothing else this saves you rebuilding build scripts > > Can you elaborate on this? How would a custom env var cause build scripts and integration from...

> Independently of that: adding a build script/env var is helpful to get rid of the feature shuffling in https://github.com/tokio-rs/tracing/blob/master/tracing/src/level_filters.rs and could make `#[instrument]` truly be a nop in case...

Here's a macro with a better error message for asserting types are equal: ``` macro_rules! static_assert_size { ($ty:ty, $size:expr) => { const _: [(); $size] = [(); ::std::mem::size_of::()]; }; }...

> Another option is to specify your feature as a platform-specific one if possible, e.g. with: That's clever! I didn't realize cargo would unify the features across target-specific tables like...

```toml [final-excludes] third-party = [ { name = "transitive-dep", git = "ssh://git@redacted/transitive-dep.git" } ] ```