Repository navigation
chore: centralise shared dependencies in the workspace manifest - #69
Merged
codemagician1949 merged 1 commit intoAug 25, 2026
Conversation
soroban-sdk was already inherited, but everything else was restated per crate, so keeping the four contracts in step depended on remembering to edit five files. This moves the rest to the workspace root. [workspace.package] now carries version, edition and rust-version, and each crate inherits them with `<field>.workspace = true`. Bumping the MSRV or moving to a new edition is one edit rather than five, and the contracts can no longer drift onto different editions without somebody deciding to. [workspace.dependencies] gains: - ed25519-dalek and rand, previously pinned only inside invoice-registry. invoice-registry still declares the rand_core feature locally, since the feature is specific to how that crate uses the dependency while the version is not. - The three intra-workspace path dependencies. A crate that takes on a sibling no longer restates the relative path, and the root package's dev-dependencies stop being a second place where those paths live. Cargo.lock is unchanged by this commit, which is the check that matters: the resolved dependency graph is identical, so this is purely a change in where the versions are written down and not a change to what gets compiled. Verified that a single bump propagates - editing soroban-sdk in [workspace.dependencies] alone moves all four contracts together, which was the point of the issue. Closes IntensifierLab#7
Contributor
|
Nice job @definurse13 |
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #7
soroban-sdkwas already inherited, but everything else was restated per crate — so keeping the four contracts in step depended on remembering to edit five files. This moves the rest to the workspace root.[workspace.package]Now carries
version,editionandrust-version, with each crate inheriting via<field>.workspace = true.Bumping the MSRV or moving to a new edition is one edit rather than five, and the contracts can no longer drift onto different editions without somebody actively deciding to.
[workspace.dependencies]Gains:
ed25519-dalekandrand, previously pinned only insideinvoice-registry.invoice-registrystill declares therand_corefeature locally — the feature is specific to how that crate uses the dependency, while the version is not. That split is the point: versions centralise, features stay where they are used.dev-dependenciesstop being a second place those paths are written down.The check that matters:
Cargo.lockis unchangedNothing in this PR alters the resolved dependency graph. The lockfile is byte-identical, which is the evidence that this is purely a change in where versions are written down and not a change to what gets compiled. A refactor of this kind that quietly moved a version would be much worse than not doing it at all.
I also verified the actual goal rather than assuming it: editing
soroban-sdkin[workspace.dependencies]alone does move all four contracts together.Acceptance criteria
soroban-sdkand common deps in workspaceVerification
cargo check --workspace,cargo test --workspace, andcargo build --release --target wasm32-unknown-unknown --workspaceall pass.This PR and #3 are conflict-free in either merge order. They touch disjoint file sets by construction — this one only
Cargo.tomlfiles, #3 only.rsfiles. I merged them both ways locally againstmainto confirm rather than assume: zero conflicts each way, both orders produce an identical tree, and the merged result passes the full gate. Whichever you merge first, the other needs no rebase.