Repository navigation
fix(readme): describe the aarch64 Crypto Extension probe (LAB-4654) - #267
Conversation
cachekit-core 0.7.0 replaced the aarch64 NEON check with a runtime probe for the Armv8 Crypto Extension AES instructions, and the core-ts 0.2.1 binding embeds it. The README still described the cachekit-core 0.6 behaviour (true on every aarch64 build).
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Hardware acceleration probe documentation packages/cachekit/README.md |
The aarch64 description now specifies a runtime probe for AES instructions and a false result when the Crypto Extension is absent. The documentation identifies cachekit-core 0.7.0. The x86/x86_64 probe and Cloudflare Workers result remain unchanged. |
Priority:
Estimated code review effort: 1 (Trivial) | ~3 minutes
Change: Other
Possibly related PRs
- cachekit-io/cachekit-ts#245: This PR concerns the binding transition to core 0.7.0, which this README update also references.
Suggested reviewers: kodus-27b
Merge Risk: 
822c7
-
The documentation update is consistent with the stated runtime probe behavior and is ready to merge.
Pre-merge checks: 
-
Check name Status Explanation Title check The title clearly and concisely describes the README correction for the aarch64 Crypto Extension probe. Description check The description directly explains the README change, its technical basis, and the preserved platform-specific behaviour. Docstring Coverage No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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 @coderabbitai help to get the list of available commands.
![kodus-27b[bot]](https://avatars.githubusercontent.com/u/223823690?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
The "Is AES hardware-accelerated on this host?" paragraph of
packages/cachekit/README.mdstill described cachekit-core 0.6:trueon every aarch64 build, from a NEON check. cachekit-core 0.7.0 replaced that with a runtime probe for the Armv8 Crypto Extension's AES instructions (cachekit-io/cachekit-core#77), and the published binding now embeds it. This PR rewrites the aarch64 clause to match, in the same words as the cachekit-rs README. The x86/x86_64 AES-NI clause and the wasm32falseclause keep their meaning.Binding evidence (inspected 2026-10-28):
@cachekit-io/cachekit-core-ts0.2.1 aslatest, published 2026-10-28T05:20:11Z.npm packof@cachekit-io/cachekit-core-ts-linux-arm64-gnu@0.2.1and@cachekit-io/cachekit-core-ts-darwin-arm64@0.2.1, thenstringson each native addon binary: both showcachekit-core-0.7.2, and neither showscachekit-core-0.6..main@ f8f9806,packages/cachekit-core-ts/package.jsonreads"version": "0.2.1".@cachekit-io/cachekitdepends on the binding asworkspace:*, so the next cachekit release pins core-ts 0.2.1. The README ships inside that package, so thisfix(readme)change should land before it, so that the release carries the corrected text. The wasm binding is not a condition: it reportsfalseon wasm32 whatever core it embeds.grep -n -E 'NEON|every aarch64|cachekit-core 0\.6' packages/cachekit/README.mdprints nothing on this head. Prettier passes.