Deprecating or removing rustc-serialize from the ecosystem

[mgattozzi]

Recently @tomaka brought this frustrating item up in that we can't compile crates to wasm depending on rustc-serialize. Currently there are 658 crates dependent on it out of 14k+ crates, but crates.io is limited and doesn't count crates that depend on it through transitive use of other crates, so I'm sure that number is higher than that.

This isn't necessarily just a wasm issue either. With serde being on 1.x and the defacto blessed crate I think we should finally consider what should be done with this crate. It hasn't seen any updates in over a year, is part of the rust-lang-deprecated org, and isn't a community standard anymore. If we want people to have a good experience using Rust getting rid of issues like this is a must.

Thoughts?

[tomaka]

Thank you for opening an issue! 😅

Merging this PR and publishing version would solve a lot of frustration: rust-lang-deprecated/rustc-serialize#190

[CryZe]

It isn‘t just rustc-serialize either. Lots of other crates important to the ecosystem like chrono fail to compile too. And that had an outstanding PR that just doesn‘t move ahead (i.e. waiting on the maintainers) as well.

Also removing rustc-serialize from the ecosystem is mostly just an issue with semver. num is one of those crates in the ecosystem that still depends on rustc-serialize, because num is still on 0.1. So until 0.2 they can‘t move away from rustc-serialize. So that‘s one of those very popular crates that still brings rustc-serialize into a lot of up to date projects.

[tomaka]

In general there are lots of crates that depend on rustc-serialize even when it's not useful.

Generally the fix is to make rustc-serialize an optional dependency, which is good.
But then in order not to break backward compatibility, rustc-serialize is made default, which is good.
But then the problem is that crates generally don't use default-features = false on their dependencies, which means that they will pull rustc-serialize even when it's unnecessary.

[mgattozzi]

I know some things there's not much we can do about some crates (i.e. chrono and others) but in the case of the time crate (if it breaks not sure) that chrono depends upon and rustc-serialize that's something possible since it's associated with Rust.

[est31]

Isn't this something the ecosystem WG could tackle?

[mgattozzi]

It might be! This is definitely a cross WG concern

[waywardmonkeys]

Many of the crates listed as reverse dependencies only use it as a dev dependency or as an optional feature ...

[BelfordZ]

Any workarounds for this? Would really love to compile to web assembly =(

[alexcrichton]

I'm going to close this since there's not much we can do about this other than helping to update existing crates, which we're already doing.