fix(perf): reduce Akamai CryptoJS bundle size

[jthorupp]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Raised from a customer report that Akamai SDK initialization consumes approximately 45 ms of a 60 ms initialization CPU budget.

Describe the solution you've provided

Replace the crypto-js root import with targeted imports for core, SHA-1, SHA-256, HMAC, and Base64. This avoids bundling unused ciphers, hash algorithms, modes, and padding implementations while preserving the existing synchronous crypto API.

The HMAC implementation now also accesses Base64 and Hex through the imported CryptoJS namespace instead of the undeclared CryptoJS global. Direct test vectors cover SHA-1 and SHA-256 hashes and HMACs in both Hex and Base64.

Describe alternatives you've considered

Targeted semver imports and publishing an unbundled ESM entry point could provide additional savings, but they affect shared SDK behavior or the public package layout. They are intentionally excluded so this PR remains a low-risk import-graph optimization matching the approach already accepted for the Fastly SDK in #1795.

Additional context

Measured after building with:

yarn workspaces foreach -pR --topological-dev --from '@launchdarkly/akamai-server-edgekv-sdk' run build

EdgeKV artifact	Raw	Gzip	Brotli
ESM	272,844 -> 213,975 bytes (-21.58%)	81,316 -> 58,334 bytes (-28.26%)	67,973 -> 50,037 bytes (-26.39%)
CJS	272,462 -> 213,593 bytes (-21.61%)	81,114 -> 58,130 bytes (-28.34%)	67,797 -> 49,904 bytes (-26.39%)

Validated with the common Akamai SDK and EdgeKV SDK unit tests and lint checks.

---

Note

Overview
Shrinks the Akamai EdgeKV SDK bundle by replacing the full crypto-js entry import with crypto-js/core plus side-effect imports for SHA-1, SHA-256, HMAC, and Base64 only, so unused ciphers and algorithms are not pulled into the build (reported ~21% smaller raw artifacts and ~28% smaller gzip).

CryptoJSHasher and CryptoJSHmac now resolve algorithms and encodings through the imported CryptoJS namespace (CryptoJS.algo.*, CryptoJS.enc.*) instead of separate crypto-js subpath default imports. HMAC digest encoding follows the same pattern, removing reliance on an implicit global CryptoJS for Base64/Hex.

Adds crypto.test.ts with fixed vectors for SHA-1 and SHA-256 hashes and HMACs in hex and base64 to lock behavior after the import change.

^{Reviewed by Cursor Bugbot for commit c7b98a6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jthorupp]

Tested this in our Akamai EdgeWorker sandbox. On a cold start, init_cpu_time dropped from 41.428ms to 5.746ms, an 86% reduction.

This is a meaningful improvement for us since the previous bundle intermittently hit Akamai's init CPU timeout. These are sandbox results, though, so we need a production deployment before drawing firm conclusions about real-world impact. These numbers seem a little bit too optimistic imo.

---

Edit:

Did some other tests in the sandbox and I found tha a cold EdgeWorker initialization dropped from ~41.4ms to ~31.9ms after this change, roughly a 23% reduction. Warm runs have no init cost. These are sandbox results, so we still need production data to quantify the real-world impact.

[joker23]

Hi @jthorupp - thank you for the contribution! I went ahead and change the title prefix to fix to ensure that our release automation will generate a patch release for this. I'll kick off the rest of the CI jobs now.

[joker23]

CI failures are due to forked PRs not having access to super secret stuff (expected). I am going to merge this since I think there are good fixes here. Thanks @jthorupp! Be on the look out for a new patch version later today.

I've created internal tickets for you other suggestions as well. I would expect a small patch soon for the targeted semvar imports, but likely a bit longer to address overall tree-shaking of our common module (need to do more thorough testing on that one to convince me that the work was done right).

[jthorupp]

CI failures are due to forked PRs not having access to super secret stuff (expected). I am going to merge this since I think there are good fixes here. Thanks @jthorupp! Be on the look out for a new patch version later today.

I've created internal tickets for you other suggestions as well. I would expect a small patch soon for the targeted semvar imports, but likely a bit longer to address overall tree-shaking of our common module (need to do more thorough testing on that one to convince me that the work was done right).

Thanks for merging! I'll be on the lookout for more optimisations and post suggestions if I find any 🙂