Big int

[ArnabChatterjee20k]

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR adds bigint attribute support to the Appwrite CLI SDK generator, enabling users to define 64-bit integer attributes in appwrite.config.json for both collections and tables. The implementation follows the existing integer type pattern closely.

Key changes:

• \"bigint\" is added to the type enum in both AttributeSchema and ColumnSchema in config.ts, making it a valid option in config files.
• case \"bigint\" branches are added to createAttribute and updateAttribute in attributes.ts, delegating to databasesService.createBigIntAttribute / updateBigIntAttribute with the same parameter set (key, required, min, max, xdefault, array).
• min and max were already validated via int64Schema (INT64 range, coerced to JS bigint) before this PR; the new type correctly benefits from that validation.

Observation: The default field remains z.any() across the schema. For a bigint attribute, an out-of-range default value will pass config validation silently and only fail when the API call is made. Aligning the default field validation with int64Schema for bigint type would provide a better developer experience.

The PR description, test plan, and related-issue sections are empty — it would be helpful to document the motivation and how the changes were tested.

Confidence Score: 5/5

Safe to merge; changes are minimal, well-structured, and mirror the existing integer pattern without introducing regressions.

All findings are P2 (the unvalidated default field for bigint is a quality improvement, not a blocking bug). The core create/update paths are correct, and the schema enum additions are complete for both collections and tables.

No files require special attention; the only observation is the missing range validation for the default field in config.ts.

Important Files Changed

Filename	Overview
templates/cli/lib/commands/config.ts	Adds "bigint" to both AttributeSchema and ColumnSchema type enums; min/max are already validated via int64Schema, but default remains z.any() with no bigint range check.
templates/cli/lib/commands/utils/attributes.ts	Adds case "bigint" handlers in both createAttribute and updateAttribute, mirroring the existing integer pattern by calling createBigIntAttribute/updateBigIntAttribute with the expected parameters.

Comments Outside Diff (1)

1. templates/cli/lib/commands/config.ts, line 219 (link)

   default not validated against int64 range for bigint type

   min and max for all attribute types are validated through int64Schema (which enforces the INT64 range and coerces to bigint), but the default field is typed as z.any() with no range validation. For a bigint attribute this means a user could specify an out-of-range default value in appwrite.config.json — the config will pass schema validation, but the subsequent createBigIntAttribute/updateBigIntAttribute API call will fail with a server-side error that is harder to diagnose.

   Consider applying int64Schema (or at least a conditional .refine) for the default field when type === "bigint", similar to how min/max are handled. A cross-field refinement at the schema level would catch this early with a clear error message.

_{Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/mas..." | Re-trigger Greptile}