Wallets, TypeScript Traps, and an Honest Decision About Credo

During the past two weeks, the author developed a functional Heka Web Wallet Chrome extension, which could generate a cryptographic key pair, derive a did:jwk identity, interact with the Heka identity service, and store SD-JWT Verifiable Credentials locally. Although the extension worked, the codebase was messy, with tangled commits and TypeScript errors.

The author's mentor, Alexander, pointed out that the GPG challenge module and GitHub OAuth module were both inside the heka-identity-service, which is not ideal. Moving the modules helped clarify the Identity Service's role, as it should only read contributor data from the Auth Service.

Another significant issue raised by Alexander was the use of Credo-TS in the web wallet. The author initially thought using Credo's abstraction layer would be beneficial, but decided to run a spike first. The spike revealed that the express import issue had been resolved in Credo 0.7.0 and that the package provides a browser-field shim compatible with Vite.

However, the bundle size increased significantly from 53 KB to over 400 KB, causing the popup to take longer to render and negatively impacting user experience. Consequently, the author decided to stick with the hand-rolled implementation.

Additionally, the author encountered a TypeScript issue while working on the contributor credential service. The use of `as const` made the `_sd` array a readonly tuple, which clashed with the mutable string[] expected by Credo's type. To resolve this, the author created a new mutable array and explicitly typed the return value.

Another TypeScript hiccup involved a redundant type cast in the format field, which caused TypeScript to infer the union type instead of the specific literal. The fix required forcing TypeScript to narrow the type to the desired literal.