fix(deps): take whatsapp-rust 0.7.0 from crates.io - #12
Conversation
The core publishes to the registry now, so the dependency no longer has to track a branch: a version is reproducible without pinning a commit, and consumers stop needing the git URL to resolve. That moves the sources the type generator reads. A published crate is unpacked on its own, so `wacore` and `whatsapp-rust` sit side by side as `<crate>-<version>` rather than nested in one repository — the generator looked only for the repository shape and would have failed, loudly now rather than silently, but failed. It resolves both: registry layout first, keyed by the versions in the lock file, then the git checkout or a sibling clone. The guard checks the directories each layout actually yields. Output is unchanged at 183 types, byte-identical to the committed file, which matches 0.7.0 carrying no type changes.
|
Warning Review limit reached
Next review available in: 4 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f9690ec21
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… root Two ways the registry lookup could read the wrong sources. It took the first directory under registry/src. That path holds one entry per registry, so a private registry beside crates.io — or a leftover from an older protocol — could be picked while the packages sit under another, failing with sources that are present. It now looks for a root holding both locked packages. And it matched on version alone. A dependency temporarily on a git revision or a patched path can share a version with a registry copy still in the cache, so the generator would have emitted declarations for a revision Cargo was not going to compile — silently, since a plausible version was found. Package stanzas are parsed now, and the registry layout is used only when the lock says that is where the package comes from.
|
Both valid, both fixed in First registry root wins — Verified by planting a decoy that sorts first: Version matched without checking the source — the sharper of the two. A dependency temporarily on a git revision or a patched path can share a version number with a registry copy still in the cache, so the generator would have read that copy and emitted declarations for a revision Cargo was never going to compile. Silently, because a plausible version was found, and without reaching the git fallback it advertises. Fixed by parsing Verified by rewriting the lock so Output is unchanged: 183 types, byte-identical to the committed file, drift check passes, codegen clippy clean. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8c1369ab15
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .find(|root| { | ||
| root.join(format!("whatsapp-rust-{core}")).is_dir() | ||
| && root.join(format!("wacore-{wacore}")).is_dir() | ||
| }) |
There was a problem hiding this comment.
Although this now searches every registry root, the new .find predicate still discards the source parsed from Cargo.lock and compares only crate names and versions. If both crates.io and a private registry or mirror contain whatsapp-rust and wacore at these versions, read_dir may select either root, so codegen can read different sources from those Cargo compiles. Resolve the root associated with each locked registry source rather than accepting the first root containing matching directory names.
Useful? React with 👍 / 👎.
1 participant
The core publishes to the registry now, so this stops tracking a branch. A version is reproducible without pinning a commit, and anyone depending on this crate no longer needs the git URL to resolve.
Why this touches the codegen
Switching registries moves the sources the type generator reads off disk. A published crate is unpacked on its own, so the two roots are siblings:
while a git checkout or working clone nests them in one tree (
root/wacore/src,root/src). The generator only knew the repository shape, so on its own this change would have failed — loudly, thanks to #10, but failed, andgenruns before anything else inbun run build.It now resolves the registry layout first, keyed by the versions in
Cargo.lock, and falls back to the git checkout or a sibling clone. The guard checks whichever directories the resolved layout actually yields, rather than a fixed list that only made sense for one of them.Verified
All three layouts, by exit code rather than by diff:
Output is byte-identical to the committed file, so the drift check added in #10 passes — which also confirms your note that 0.7.0 carries nothing new: same 183 types.
cargo clippy --all-targets --all-featuresclean,bun run buildfine,bun test tests/87 pass / 0 fail (7 skipped are the E2E pair needing the local mock server).Summary by cubic
Switch
whatsapp-rustto the published0.7.0on crates.io and harden the type generator to correctly resolve registry sources fromCargo.lock, with git/sibling fallback. Builds are reproducible without a git URL, and generated types are unchanged.Refactors
Cargo.lockpackage stanzas; use the registry layout only when the lock’s source is a registry.registry/srcroots and pick the one containing bothwhatsapp-rust-<ver>andwacore-<ver>; otherwise fall back to Cargo git cache or a sibling clone.wacore/src,src/features,src/types,src/send) to prevent partial generation.Dependencies
whatsapp-rust0.7.0from crates.io.Cargo.locknow pinswacore,wacore-*,waproto, andwhatsapp-rustto0.7.0from the registry.Written for commit 8c1369a. Summary will update on new commits.