> My project will still get 1.0.2, so it will still have the security hole. Right. To mitigate that you would regularly run `npm audit` or even just `npm upgra

> My project will still get 1.0.2, so it will still have the security hole. Right. To mitigate that you would regularly run `npm audit` or even just `npm upgrade` – and test afterwards of course. I'm not completely sold, but I do think it's a very interesting idea. > Can I ask for a warning if I'm getting two different versions linked into the same binary? Yes. That was the lint I linked in my last post. Alternatively, you can run `cargo tree --duplicates`. > "I really, really don't think think you should be using 1.0 any more" That's called "yanking". Personally I think it has limited usefulness, but it exists. https://doc.rust-lang.org/cargo/commands/cargo-yank.html https://doc.rust-lang.org/cargo/commands/cargo-yank.html > And what happens if both versions get pulled in, but the package in question uses an external data file whose format changed between 1.0 and 1.1? If it uses something like `include!`, both copies will be compiled in (and maybe optimized later by the linker). If it's truly "external" like hosted on some website outside the package manager, then it just means the author broke their package. Maybe I misunderstood your question. > one of my dependencies constructs a foo using X 1.0, is that value of a different type than a foo constructed by X 1.1? I believe they are always different types. Cargo encourages but doesn't enforce semver, so anything can change between versions, including private fields or enum variants behind non_exhaustive, etc. So they're treated as different and you need to convert between them. Although this might only be true for major versions; I don't know off the top of my head. To work around it you can convert the types at crate boundaries, or the package author can use the so-called "semver trick" [1] [1]: https://github.com/dtolnay/semver-trick https://github.com/dtolnay/semver-trick