Exact

Exact Union RegExp

Repository files (latest commit first)

Filename	Latest commit message	Latest commit date
David Charlot b1d7e1e2b2 lockfiles: three workspaces' locks did not list a dependency jcp-efficiency grew ... `jcp-efficiency` gained a `serde` dependency. Its own workspace's lock (`jcp/jcp-rs`) records it; the three other workspaces that reach that crate through a cross-workspace path dependency do not, so on current main: cargo metadata --locked in sandbox-rs, jouledesk-rs, joulehook-rs FAILS Measured both ways — those three fail `--locked` at 8f62e388 and pass with this commit. Nothing else moved: one `"serde",` line per lock, resolved by cargo itself rather than written by hand. Nothing caught it because no workflow passes `--locked`, so CI silently re-resolves and goes green while the committed lock is wrong. The visible symptom is instead that building any of those three workspaces leaves a dirty `Cargo.lock` behind, which is how this surfaced: a `cargo test` in sandbox-rs dirtied the tree while I was verifying the commit before this one. This is the shape the repo keeps producing — a shared crate's manifest changes and only its own workspace's lock is refreshed. There are ~25 workspaces and no single build that covers them, so the rule has to be: after changing a crate's dependencies, refresh every lock that names it (`grep -rl 'name = "<crate>"' --include=Cargo.lock`), not just the one beside it. Co-Authored-By: Claude Opus 5 <[email protected]>		2026-10-10 10:01:38 -04:00
..
crates	sandbox: a setup assertion walked a tree that still held the warm-up worker	2026-10-10 09:58:26 -04:00
Cargo.lock	lockfiles: three workspaces' locks did not list a dependency jcp-efficiency grew	2026-10-10 10:01:38 -04:00
Cargo.toml	msrv: raise the rust-version floor to 1.97 across the workspaces	2026-07-23 00:17:08 -04:00