fix: re-expose sizes

[spiral-ladder]

restores #328

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request restores previously removed size constants for cryptographic structures in the N-API bindings to ensure compatibility and ease of use. Additionally, it updates the zapi dependency to a more recent version to maintain project alignment.

Highlights

• Re-exposure of size constants: Restored the COMPRESS_SIZE and SERIALIZE_SIZE constants for both PublicKey and Signature structures in the N-API bindings.
• Dependency update: Updated the zapi dependency in build.zig.zon to point to a newer commit hash.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds COMPRESS_SIZE and SERIALIZE_SIZE constants to the PublicKey and Signature structs in the Zig NAPI bindings and updates the zapi dependency. The review feedback identifies style guide violations in the new additions, specifically regarding the ordering of struct members (fields should precede constants) and the requirement to use explicit types like u32 for constants instead of relying on type inference.

[gemini-code-assist]

The current structure of the PublicKey struct violates the repository style guide regarding member ordering and type explicitness:

1. Member Ordering: Per Rule 256, the order should be fields, then types/constants, then methods. Currently, js_meta and the new constants are placed before the raw field.
2. Explicit Types: Per Rule 44, explicitly-sized types like u32 should be used for everything instead of relying on inferred comptime_int types for constants.

Moving the field to the top and adding explicit types improves adherence to the style guide and code clarity.

    raw: NativePublicKey = .{}, 

    pub const js_meta = js.class(.{});

    pub const COMPRESS_SIZE: u32 = NativePublicKey.COMPRESS_SIZE;
    pub const SERIALIZE_SIZE: u32 = NativePublicKey.SERIALIZE_SIZE;

References

1. Rule 256: Order matters for readability... the order is fields then types then methods. ^(link)
2. Rule 44: Use explicitly-sized types like u32 for everything, avoid architecture-specific usize. ^(link)

[gemini-code-assist]

Similar to the PublicKey struct, the Signature struct should follow the repository style guide for member ordering and explicit typing:

1. Member Ordering: The raw field should precede the constants (Rule 256).
2. Explicit Types: Constants should use explicitly-sized types like u32 (Rule 44).

    raw: NativeSignature = .{}, 

    pub const js_meta = js.class(.{});

    pub const COMPRESS_SIZE: u32 = NativeSignature.COMPRESS_SIZE;
    pub const SERIALIZE_SIZE: u32 = NativeSignature.SERIALIZE_SIZE;

References

1. Rule 256: Order matters for readability... the order is fields then types then methods. ^(link)
2. Rule 44: Use explicitly-sized types like u32 for everything, avoid architecture-specific usize. ^(link)