Skip to content

Conversation

@martinfrances107
Copy link

@martinfrances107 martinfrances107 commented Jul 21, 2025

I love this crate it is really useful.

In part this is a field report from a upstream application

I am writing a app using the leptos framework
Leptos makes extensive use of the dashmap crate.
In my app - when I run

cargo tree -d 

I am looking at the large number of duplicate crates ( many different version of the same crate in the build chain )

My current focus is to simplify my build time/size by clearing issues with hashbrown, proc_macro2 and serde

in short I ran cargo update here, and think as it bubbles up 2 levels it would fix my problem

I hope this helps

@cxw620
Copy link

cxw620 commented Aug 1, 2025

AFAIK, one crate that serves as a library should not include Cargo.lock, see here: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html. So I think it's time to delete it and ignore it in .gitignore in the comming 7.0.0 stable version.

Let's wait for @xacrimon's comment.

@cuviper
Copy link
Contributor

cuviper commented Sep 18, 2025

The lock file is completely irrelevant to any dependents of this crate. The downstream root crate/workspace will have their own lock file independent of whatever you have here. It only really matters for your own development and CI.

See also: https://blog.rust-lang.org/2023/08/29/committing-lockfiles/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants