optimize nix build cache hits & local compile time with cargo-hakari

[insipx]

crane docs highly recommend integrating cargo-hakari to reduce cache misses. cargo hakari should also optimize local building and reduce re-builds by optimizing the dependency graph of the cargo workspace.

read about how hakari works here

workspace-hack is used on some other large projects as well, like

rustc
firefox

this PR follows the instructions in cargo-hakari docs and is completely auto-generated. it adds a CI workflow to verify the config. you can run hakari locally with nix develop .# --command cargo hakari verify or nix develop .# --command cargo hakari generate

[insipx]

This PR is part of a stack of 4 bookmarks:

1. trunk()
2. push-nwxxwzqwnxoq
3. push-wztqyrwztzqs ← this PR
4. push-lssnrpnpzvll
5. push-mxrnnusmvnut

---

Created with jj-stack

[claude]

Claude finished @insipx's task —— View job

---

PR Review - cargo-hakari Integration

Review Date: 2026-02-11 20:12 UTC

---

Summary

This PR successfully integrates cargo-hakari to optimize workspace dependency unification, which should improve Nix cache hits and reduce local rebuild times. The implementation follows best practices and is entirely auto-generated as intended.

Key Findings

✅ Strengths:

• Proper CI integration: The workflow correctly validates both cargo hakari generate --diff and cargo hakari manage-deps --dry-run (.github/workflows/lint-workspace.yml:24-31)
• Correct WASM handling: Properly excludes mio/tokio and bindings_wasm to avoid feature conflicts (.config/hakari.toml:28-33)
• Platform coverage: Targets appropriate platforms for development (x86_64-linux, aarch64-darwin, Android) (.config/hakari.toml:17-22)
• Tooling setup: cargo-hakari added to Nix dev environments (nix/libxmtp.nix:46, 97)
• Format exclusion: Correctly excludes the hack crate from taplo formatting (.taplo.toml:4)

Potential Concerns

⚠️ Minor Issues:

1. deny.toml cleanup may be too aggressive (deny.toml:1-39)

   • Removed 14 lines including comments about duplicate dependencies
   • While the workspace-hack should resolve many duplicates, consider preserving documentation about why certain duplicates might exist post-hakari
   • The previous [[bans.skip]] and [[bans.skip-tree]] sections were removed - verify these are truly unnecessary now

2. Missing workspace.resolver check (.config/hakari.toml:15)

   • Config sets resolver = "3" but doesn't verify root Cargo.toml matches
   • Root Cargo.toml correctly has resolver = "3" (Cargo.toml:25), but hakari docs recommend verification
   • Not a bug, but worth noting

Security & Best Practices

✅ No security concerns identified:

• Generated code is minimal (stub lib.rs and build.rs)
• No credentials or secrets
• Uses well-established tool (hakari) used by rustc and firefox

✅ Follows project conventions:

• Matches existing Cargo.toml patterns
• Integrates with existing Nix infrastructure
• Uses workspace metadata appropriately

Performance Considerations

✅ Expected benefits:

• Unified feature resolution across workspace
• Better Nix cache locality
• Reduced local recompilation on dependency changes
• crane docs cite this as high-impact optimization

Test Coverage

✅ CI adequately validates:

• Hack crate stays current with cargo hakari generate --diff
• All crates depend on hack with cargo hakari manage-deps --dry-run
• No additional test coverage needed for auto-generated code

Recommendations

1. Optional: Consider adding a comment in deny.toml explaining that workspace-hack reduces duplicate dependencies
2. Optional: Document the hakari workflow in CLAUDE.md for future contributors (e.g., when to run cargo hakari generate)
3. Before merge: Verify CI passes with the new validation steps

Final Assessment

Approve with minor suggestions. This is a well-executed optimization following established patterns. The auto-generated nature and crane/hakari best practices make this low-risk. The only consideration is preserving institutional knowledge about dependency management that may have been in the removed deny.toml comments.

---

Todo List:

• Review hakari configuration
• Review CI integration
• Review generated workspace-hack crate
• Review workspace crate updates
• Check for potential issues
• Provide final feedback

---

[macroscopeapp]

Add cargo-hakari workspace-hack crate and CI checks to improve Nix build cache hits and local compile time across Rust workspace

Introduce the generated xmtp-workspace-hack crate, add cargo-hakari config, wire CI lint to verify hack generation and dependency presence, and update Nix shells to include cargo-hakari and library paths.

📍Where to Start

Start with the cargo-hakari configuration in .config/hakari.toml, then review the CI integration in .github/workflows/lint-workspace.yml and the crate manifest in crates/xmtp-workspace-hack/Cargo.toml.

---

Macroscope summarized 24449cb.

[macroscopeapp]

Re-evaluating approvability for a370386

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.25%. Comparing base (8d5ce50) to head (24449cb).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3163      +/-   ##
==========================================
- Coverage   74.28%   74.25%   -0.03%     
==========================================
  Files         448      448              
  Lines       55750    55750              
==========================================
- Hits        41413    41398      -15     
- Misses      14337    14352      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Dismissing my prior approval and re-evaluating approvability for 126ad37

[macroscopeapp]

Re-evaluating approvability for 796f015

Dismissing my prior approval and re-evaluating approvability for 19bb54f

[macroscopeapp]

Re-evaluating approvability for b9154cd

Dismissing my prior approval and re-evaluating approvability for b9154cd

[macroscopeapp]

Re-evaluating approvability for d01a6e0

Dismissing my prior approval and re-evaluating approvability for 2d8a460

[macroscopeapp]

Re-evaluating approvability for ae2f637

Dismissing my prior approval and re-evaluating approvability for 3debeee

[macroscopeapp]

Re-evaluating approvability for 9926a9a

Dismissing my prior approval and re-evaluating approvability for bab2023

[macroscopeapp]

Re-evaluating approvability for 24449cb

Dismissing my prior approval and re-evaluating approvability for a07dd3c

[neekolas]

Would be helpful to know when this list of inputs would need to change.

[insipx]

I was getting build errors in android, I think some buildscripts need the LD_LIBRARY_PATH to be set in order to work correctly. I've found its mostly an issue with the zstd/openssl dependencies