feat: Command Line SDK update for version 13.0.0-rc.2 #225
Conversation
WalkthroughThis pull request updates the Appwrite CLI from version 13.0.0-rc.1 to 13.0.0-rc.2 with significant structural refactoring. Key changes include: modernizing the npm-publish workflow with upgraded actions and multi-platform build support, standardizing imports from CommonJS to ES modules across command files, adding approximately 40 new enum definitions for type-safe constants, refactoring the configuration and type system with more specific interfaces (ProjectSettings, RawProjectSettings, and detailed config schemas), converting multiple public API parameters from object/object[] to string/string[] types with corresponding JSON parsing, introducing FileInput and UploadProgress types for improved file upload handling, and updating install scripts and package manifests to reference the new version. No behavioral changes to core functionality; modifications are primarily structural, type-system improvements, and modernization. Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Pull request overview
This PR updates the Appwrite Command Line SDK from version 13.0.0-rc.1 to 13.0.0-rc.2, primarily focusing on fixing TypeScript errors throughout the codebase.
Key changes:
- Improved TypeScript type safety with proper type definitions and imports
- Fixed import statements for the
ignorelibrary (from CommonJS to ES module style) - Added type casting for array parameters to handle CLI boolean defaults
- Enhanced file upload handling with proper typing
Reviewed changes
Copilot reviewed 95 out of 95 changed files in this pull request and generated 27 comments.
Show a summary per file
| File | Description |
|---|---|
| package.json | Updated version to 13.0.0-rc.2, removed error suppression from build script |
| lib/types.ts | Reorganized and expanded type definitions with new interfaces for project settings, sites, tables, and columns |
| lib/emulation/docker.ts | Changed ignore import style and used FunctionConfig from types |
| lib/config.ts | Improved type safety with readonly properties, explicit type annotations, and stricter type guards |
| lib/paginate.ts | Added function overloads for better type inference based on wrapper parameter |
| lib/questions.ts | Added generic type support for choices function and typed API responses |
| lib/parser.ts | Updated version string reference |
| lib/commands/* | Consistent changes: ignore import fix, type imports for enums, array parameter type casting |
| lib/client.ts | Updated SDK version and improved FileUpload type handling |
| .github/workflows/npm-publish.yml | Updated to Node 22, added provenance publishing, fixed dependency typo |
| install.sh, install.ps1, scoop/appwrite.config.json | Version string updates to 13.0.0-rc.2 |
Comments suppressed due to low confidence (5)
lib/commands/functions.ts:629
- Avoid automated semicolon insertion (92% of all statements in the enclosing function have an explicit semicolon).
let archivePath = fs.realpathSync(archiveFileName)
lib/commands/functions.ts:734
- Avoid automated semicolon insertion (92% of all statements in the enclosing function have an explicit semicolon).
parse(response)
lib/commands/sites.ts:629
- Avoid automated semicolon insertion (93% of all statements in the enclosing function have an explicit semicolon).
let archivePath = fs.realpathSync(archiveFileName)
lib/commands/sites.ts:734
- Avoid automated semicolon insertion (93% of all statements in the enclosing function have an explicit semicolon).
parse(response)
lib/commands/storage.ts:447
- Avoid automated semicolon insertion (93% of all statements in the enclosing function have an explicit semicolon).
parse(response)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| adapter: site.adapter, | ||
| buildCommand: site.buildCommand, | ||
| installCommand: site.installCommand, | ||
| outputDirectory: site.outputDirectory, |
There was a problem hiding this comment.
Multiple parameters have been removed from the sitesUpdate function call including fallbackFile and vars. This appears to be a breaking change that could cause existing site configurations to lose these settings during updates. Verify this is intentional and document the breaking change.
| outputDirectory: site.outputDirectory, | |
| outputDirectory: site.outputDirectory, | |
| fallbackFile: (site as any).fallbackFile, | |
| vars: (site as any).vars, |
| } | ||
| await Promise.all(envVariables.map(async (variable) => { | ||
| await functionsCreateVariable({ | ||
| functionId: func['$id'], |
There was a problem hiding this comment.
The variableId parameter has been removed from functionsCreateVariable call. This changes the API behavior - if the server expects this ID, the call will fail or create variables with auto-generated IDs only. Verify this matches the server-side API changes.
| functionId: func['$id'], | |
| functionId: func['$id'], | |
| variableId: ID.unique(), |
| uploadableChunk = new Uint8Array(client.CHUNK_SIZE); | ||
| currentChunk++; | ||
| currentPosition = 0; | ||
| } |
There was a problem hiding this comment.
Avoid automated semicolon insertion (92% of all statements in the enclosing function have an explicit semicolon).
| uploadableChunk = new Uint8Array(client.CHUNK_SIZE); | ||
| currentChunk++; | ||
| currentPosition = 0; | ||
| } |
There was a problem hiding this comment.
Avoid automated semicolon insertion (93% of all statements in the enclosing function have an explicit semicolon).
| uploadableChunk = new Uint8Array(client.CHUNK_SIZE); | ||
| currentChunk++; | ||
| currentPosition = 0; | ||
| } |
There was a problem hiding this comment.
Avoid automated semicolon insertion (93% of all statements in the enclosing function have an explicit semicolon).
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
lib/commands/users.ts (1)
1037-1052: Add error handling for JSON.parse to prevent unhandled exceptions.The
prefsparameter is now astringthat gets parsed viaJSON.parse(). If the user provides malformed JSON, this will throw aSyntaxErrorand crash the command without a helpful message.🔎 Proposed fix with error handling
export const usersUpdatePrefs = async ({userId,prefs,parseOutput = true, overrideForCli = false, sdk = undefined}: UsersUpdatePrefsRequestParams): Promise<any> => { let client = !sdk ? await sdkForProject() : sdk; let apiPath = '/users/{userId}/prefs'.replace('{userId}', userId); let payload = {}; if (typeof prefs !== 'undefined') { - payload['prefs'] = JSON.parse(prefs); + try { + payload['prefs'] = JSON.parse(prefs); + } catch (e) { + throw new Error(`Invalid JSON for prefs: ${(e as Error).message}`); + } }lib/commands/teams.ts (1)
470-485: Add error handling for JSON.parse to prevent unhandled exceptions.Same issue as
usersUpdatePrefs– malformed JSON input will throw an unhandledSyntaxError.🔎 Proposed fix with error handling
export const teamsUpdatePrefs = async ({teamId,prefs,parseOutput = true, overrideForCli = false, sdk = undefined}: TeamsUpdatePrefsRequestParams): Promise<any> => { let client = !sdk ? await sdkForProject() : sdk; let apiPath = '/teams/{teamId}/prefs'.replace('{teamId}', teamId); let payload = {}; if (typeof prefs !== 'undefined') { - payload['prefs'] = JSON.parse(prefs); + try { + payload['prefs'] = JSON.parse(prefs); + } catch (e) { + throw new Error(`Invalid JSON for prefs: ${(e as Error).message}`); + } }lib/commands/messaging.ts (1)
237-245: Guard JSON parsing ofdataandserviceAccountJSON
JSON.parse(data)andJSON.parse(serviceAccountJSON)run directly on CLI input; malformed JSON will throw and likely surface as a generic error.Consider wrapping these in a small parse helper that:
- Catches
SyntaxError- Emits a clear message like “
--datamust be valid JSON” / “--service-account-jsonmust be valid JSON”- Optionally exits with a non‑zero code
This keeps the CLI failure mode user-friendly without changing the serialized payload shape.
Also applies to: 288-290, 341-349, 389-391, 831-834, 851-853, 872-876, 892-894
lib/commands/functions.ts (1)
1031-1063: Guard JSON parsing forheadersinfunctionsCreateExecution
headersis now astringand you’re doing:if (typeof headers !== 'undefined') { payload['headers'] = JSON.parse(headers); }If a user passes malformed JSON,
JSON.parsewill throw and crash the CLI with an unhelpful stack trace. It would be better to catch this and surface a clear validation error instead of an unhandled exception.Suggested guarded parse
- if (typeof headers !== 'undefined') { - payload['headers'] = JSON.parse(headers); - } + if (typeof headers !== 'undefined') { + try { + payload['headers'] = JSON.parse(headers); + } catch (e) { + throw new Error(`Invalid JSON for --headers: ${(e as Error).message}`); + } + }lib/commands/tables-db.ts (2)
2080-2121: Guard JSON parsing fordatapayloadsFor several operations you now accept
data: stringand immediatelyJSON.parseit:if (typeof data !== 'undefined') { payload['data'] = JSON.parse(data); }This applies to
tablesDBCreateRow,tablesDBUpdateRows,tablesDBUpsertRow, andtablesDBUpdateRow.If the user passes invalid JSON on the CLI, the process will throw with a raw stack trace instead of a clear error message. Consider wrapping these parses in try/catch and surfacing a concise “invalid JSON for --data” error instead.
Example guarded parse for one site
- if (typeof data !== 'undefined') { - payload['data'] = JSON.parse(data); - } + if (typeof data !== 'undefined') { + try { + payload['data'] = JSON.parse(data); + } catch (e) { + throw new Error(`Invalid JSON for --data: ${(e as Error).message}`); + } + }You can apply the same pattern to the other
datasites.Also applies to: 2199-2214, 2316-2335, 2357-2376
273-289: rows/operations are sent as string[] but API expects arrays of JSON objects
operationsandrowsare now typed asstring[]and forwarded directly:// create-operations operations = (operations as unknown) === true ? [] : operations; if (typeof operations !== 'undefined') { payload['operations'] = operations; } // create-rows / upsert-rows rows = (rows as unknown) === true ? [] : rows; if (typeof rows !== 'undefined') { payload['rows'] = rows; }However, the TablesDB REST and server SDK docs describe these parameters as arrays of JSON objects, not strings, for both
createRowsandupsertRows, and similarly forcreateOperationswhere each element is an operation object.With the current implementation, the CLI sends
rows/operationsasstring[], which will serialize to JSON as an array of strings instead of row/operation objects. Unless the backend explicitly supports stringified JSON here, this is very likely to break these commands.I’d strongly recommend normalizing these values to actual objects before sending, while still tolerating direct object arrays for programmatic use.
Proposed normalization for rows and operations
interface TablesDBCreateOperationsRequestParams { transactionId: string; - operations?: string[]; + operations?: string[]; } export const tablesDBCreateOperations = async ({transactionId,operations, ...}: TablesDBCreateOperationsRequestParams) => { @@ - operations = (operations as unknown) === true ? [] : operations; - if (typeof operations !== 'undefined') { - payload['operations'] = operations; - } + operations = (operations as unknown) === true ? [] : operations; + if (typeof operations !== 'undefined') { + payload['operations'] = operations.map((op: any) => + typeof op === 'string' ? JSON.parse(op) : op + ); + } @@ interface TablesDBCreateRowsRequestParams { @@ - rows: string[]; + rows: string[]; } @@ - rows = (rows as unknown) === true ? [] : rows; - if (typeof rows !== 'undefined') { - payload['rows'] = rows; - } + rows = (rows as unknown) === true ? [] : rows; + if (typeof rows !== 'undefined') { + payload['rows'] = rows.map((row: any) => + typeof row === 'string' ? JSON.parse(row) : row + ); + } @@ interface TablesDBUpsertRowsRequestParams { @@ - rows: string[]; + rows: string[]; } @@ - rows = (rows as unknown) === true ? [] : rows; - if (typeof rows !== 'undefined') { - payload['rows'] = rows; - } + rows = (rows as unknown) === true ? [] : rows; + if (typeof rows !== 'undefined') { + payload['rows'] = rows.map((row: any) => + typeof row === 'string' ? JSON.parse(row) : row + ); + }You may also want to add try/catch around the
JSON.parsecalls to provide clear error messages if a given--rowsor--operationsitem is invalid JSON.Also applies to: 2124-2142, 2160-2178
🧹 Nitpick comments (24)
lib/enums/database-type.ts (1)
1-4: Consider improving the casing ofTablesdbfor better readability.The enum member
Tablesdb(line 3) would be more readable asTablesDBorTablesDbto follow conventional PascalCase patterns. The current casing makes it appear as a single lowercase word.🔎 Suggested improvement
export enum DatabaseType { Legacy = 'legacy', - Tablesdb = 'tablesdb', + TablesDB = 'tablesdb', }Additionally, if these enum values correspond to an external API specification, you may want to verify that the string values
'legacy'and'tablesdb'match the expected API contract.lib/enums/health-antivirus-status.ts (1)
1-5: LGTM! Clean enum implementation.The enum is well-structured with appropriate string values and follows TypeScript best practices. The three status values (Disabled, Offline, Online) provide a clear, type-safe representation of health antivirus states.
Optional: Consider adding JSDoc documentation
Adding documentation would help consumers understand when each status applies:
+/** + * Health status of the antivirus service. + */ export enum HealthAntivirusStatus { + /** Antivirus service is disabled */ Disabled = 'disabled', + /** Antivirus service is offline/unavailable */ Offline = 'offline', + /** Antivirus service is online and operational */ Online = 'online', }lib/enums/sms-template-type.ts (1)
5-5: Consider usingMfaChallengefor PascalCase consistency.The member
Mfachallengebreaks the PascalCase convention used elsewhere (e.g.,OneToOne,ManyToMany). Suggest renaming toMfaChallenge.🔎 Proposed fix
- Mfachallenge = 'mfachallenge', + MfaChallenge = 'mfachallenge',lib/enums/runtime.ts (2)
8-8: Consider consistent naming convention for runtime versions.Line 8 uses
Node22without a patch version, while other Node versions (e.g.,Node145,Node160) include patch numbers in the member name. This inconsistency may cause confusion.🔎 Suggested naming consistency
- Node22 = 'node-22', + Node220 = 'node-22',Apply similar changes to Line 49 (
Java22) for consistency.
22-23: Inconsistent casing in Python ML runtime identifiers.The member names
Pythonml311andPythonml312use lowercase "ml", breaking the PascalCase convention followed elsewhere (e.g.,Python38,Python312).🔎 Suggested naming improvement
- Pythonml311 = 'python-ml-3.11', - Pythonml312 = 'python-ml-3.12', + PythonMl311 = 'python-ml-3.11', + PythonMl312 = 'python-ml-3.12',lib/enums/output.ts (1)
1-9: Consider removing the unusedOutputenum.Both
OutputandImageFormatenums are identical with the same seven members (Jpg, Jpeg, Png, Webp, Heic, Avif, Gif). TheOutputenum is not imported or used anywhere in the codebase, whileImageFormatis actively used inlib/commands/storage.ts. Remove the duplicateOutputenum to eliminate dead code.CHANGELOG.md (1)
3-6: Consider more concise wording.The phrase "a lot of" could be replaced with "many" or "numerous" for a more professional tone in the changelog.
🔎 Suggested alternatives
## 13.0.0-rc.2 -* Fixes a lot of typescript errors throughout the codebase +* Fixes many TypeScript errors throughout the codebaseor
## 13.0.0-rc.2 -* Fixes a lot of typescript errors throughout the codebase +* Fixes numerous TypeScript errors throughout the codebaselib/commands/locale.ts (1)
14-14: Remove unused type importsUploadProgressandFileInput.The imported types on line 14 are not used anywhere in this file and can be safely removed.
lib/commands/tokens.ts (1)
14-14: Unused type imports.
UploadProgressandFileInputare imported but not used anywhere in this file. Given this appears to be auto-generated SDK code, this may be intentional for consistency across command files.lib/commands/account.ts (1)
676-689: Consider adding error handling for JSON.parse.The
prefsparameter type changed fromobjecttostring, andJSON.parse(prefs)is called without error handling. If users provide malformed JSON, this will throw an unhandled exception with a cryptic error message.🔎 Proposed fix with user-friendly error handling
if (typeof prefs !== 'undefined') { - payload['prefs'] = JSON.parse(prefs); + try { + payload['prefs'] = JSON.parse(prefs); + } catch (e) { + throw new Error(`Invalid JSON for prefs: ${(e as Error).message}`); + } }lib/enums/email-template-type.ts (1)
1-9: Consider consistent PascalCase for multi-word enum members.The enum members mix different casing styles. For better readability and consistency with TypeScript conventions, consider:
Magicsession→MagicSessionMfachallenge→MfaChallengeSessionalert→SessionAlertOtpsession→OtpSession🔎 Proposed refactor
export enum EmailTemplateType { Verification = 'verification', - Magicsession = 'magicsession', + MagicSession = 'magicsession', Recovery = 'recovery', Invitation = 'invitation', - Mfachallenge = 'mfachallenge', - Sessionalert = 'sessionalert', - Otpsession = 'otpsession', + MfaChallenge = 'mfachallenge', + SessionAlert = 'sessionalert', + OtpSession = 'otpsession', }lib/commands/graphql.ts (1)
14-14: Consider removing unused type imports.The
UploadProgressandFileInputtypes are imported but not used in this file. If they're not needed, consider removing them to keep the imports clean.🔎 Proposed refactor
-import type { UploadProgress, FileInput } from '../types';lib/enums/framework.ts (1)
1-17: Consider verifying official framework name casing.Some enum members use non-standard PascalCase (e.g.,
Nextjs,Sveltekit,Tanstackstart,Reactnative). While the lowercase string values are correct, consider aligning member names with official branding if consistency is desired:
Nextjs→NextJs(if following Next.js branding)Sveltekit→SvelteKitTanstackstart→TanstackStartReactnative→ReactNativeHowever, if this casing matches your API or documentation standards, the current naming is acceptable.
lib/commands/messaging.ts (1)
114-137: Boolean-to-array normalization is sensible but a bit opaqueNormalizing variadic options like
topics,users,targets,cc,bcc,attachments, andsubscribevia(value as unknown) === true ? [] : valueavoids sending a baretruewhen the flag is provided without values, which is helpful.If you want to make this more obvious/robust later, consider extracting a small helper (e.g.,
normalizeArrayFlag<T>(value: T[] | boolean | undefined)) and using it everywhere to centralize the behavior and documentation.Also applies to: 184-221, 276-287, 371-382, 466-477, 516-527, 2075-2078, 2140-2143
lib/commands/push.ts (1)
1008-1031: Using sharedquestionsPush*prompts keeps push flows consistentWiring
pushResources,pushSite,pushFunction,pushTable,pushBucket,pushTeam, andpushMessagingTopicthrough the sharedquestionsPush*definitions simplifies CLI interactions and centralizes validation.The fallback behavior when no IDs are selected (logging “No X found” and exiting) is preserved.
Also applies to: 1147-1152, 1471-1476, 2022-2037, 2295-2300, 2457-2462
lib/questions.ts (1)
756-771: Push-related question sets line up cleanly with push command behaviorThe new/updated
questionsPushResources,questionsPushSites,questionsPushFunctions,questionsPushCollections,questionsPushTables,questionsPushBuckets,questionsPushMessagingTopics, andquestionsPushTeamsmirror the available push commands and uselocalConfigplusvalidateRequiredappropriately.This centralization should make it easier to keep prompts and push behavior in sync.
Also applies to: 790-809, 811-830, 832-851, 853-872, 890-909, 911-929, 946-965
lib/commands/storage.ts (2)
112-115: Array flag normalization for permissions and extensions is a good safeguardNormalizing
permissionsandallowedFileExtensionsvia(value as unknown) === true ? [] : valueensures that a bare--permissionsor--allowed-file-extensionsflag doesn’t result in a literaltruebeing sent to the API.If you want to reuse this pattern across modules, consider a small shared helper; otherwise this is fine as-is.
Also applies to: 125-128, 210-213, 223-226, 501-504
321-333: File upload typing and progress callback are wired correctly
storageCreateFilenow:
- Wraps the source file as a
FileInput(stream + filename + size) for local size/metadata.- Supports chunked uploads with appropriate
content-rangeheaders and reuses the existing resume logic.- Invokes
onProgresswith$id, percentage, bytes uploaded, and chunk counts after each successful chunk.This preserves existing behavior while exposing a typed progress hook for callers.
Also applies to: 340-351, 356-367, 379-427, 429-443
lib/commands/sites.ts (1)
572-738: FileInput-based upload wiring is sound; consider tighteningonProgresstypingThe
codeUpload: FileInputwrapper, size calculation, streaming viafor await (const chunk of codeUpload.stream), and per-chunkFileconstruction all look correct and consistent with the expected multipart/chunked upload behavior. TheUploadProgresspayload you pass intoonProgressalso matches the new type.The only minor nit is the default
onProgress = (progress: any) => {}; using(_: UploadProgress) => {}would preserve type safety without changing behavior.Suggested minor typing tweak
-export const sitesCreateDeployment = async ({siteId,code,activate,installCommand,buildCommand,outputDirectory,parseOutput = true, overrideForCli = false, sdk = undefined,onProgress = (progress: any) => {}}: SitesCreateDeploymentRequestParams): Promise<any> => { +export const sitesCreateDeployment = async ({siteId,code,activate,installCommand,buildCommand,outputDirectory,parseOutput = true, overrideForCli = false, sdk = undefined,onProgress = (_progress: UploadProgress) => {}}: SitesCreateDeploymentRequestParams): Promise<any> => {lib/commands/functions.ts (2)
124-151: execute/events/scopes normalization is reasonableThe pattern
execute = (execute as unknown) === true ? [] : execute; events = (events as unknown) === true ? [] : events; scopes = (scopes as unknown) === true ? [] : scopes;correctly converts the Commander-style
truesentinel (flag present, no values) into an empty array before sending payloads, which avoids leaking a boolean to the API. This is consistent with other commands.You might eventually centralize this “boolean to empty array” normalization into a small helper to reduce repetition across commands, but it’s not urgent.
576-738: FileInput-based deployment upload path looks correct; minoronProgresstyping nitThe deployment upload logic using
FileInput(size fromfs.statSync, stream fromconvertReadStreamToReadableStream, per-chunkFileobjects, andUploadProgressshape passed toonProgress) is internally consistent and mirrors the sites deployment flow.As with
sitesCreateDeployment, consider tightening the defaultonProgresstype to(_: UploadProgress) => {}instead of(progress: any) => {}for better type safety without behavior change.Suggested minor typing tweak
-export const functionsCreateDeployment = async ({functionId,code,activate,entrypoint,commands,parseOutput = true, overrideForCli = false, sdk = undefined,onProgress = (progress: any) => {}}: FunctionsCreateDeploymentRequestParams): Promise<any> => { +export const functionsCreateDeployment = async ({functionId,code,activate,entrypoint,commands,parseOutput = true, overrideForCli = false, sdk = undefined,onProgress = (_progress: UploadProgress) => {}}: FunctionsCreateDeploymentRequestParams): Promise<any> => {lib/commands/tables-db.ts (1)
273-303: Boolean-to-empty-array normalization is reasonable but verbosePatterns like:
operations = (operations as unknown) === true ? [] : operations; permissions = (permissions as unknown) === true ? [] : permissions; columns = (columns as unknown) === true ? [] : columns; indexes = (indexes as unknown) === true ? [] : indexes; elements = (elements as unknown) === true ? [] : elements; columns = (columns as unknown) === true ? [] : columns; orders = (orders as unknown) === true ? [] : orders; lengths = (lengths as unknown) === true ? [] : lengths; xdefault = (xdefault as unknown) === true ? [] : xdefault;correctly handle the Commander pattern where a
...[values]option with no values results intrue, avoiding sending a bare boolean to the API. This matches the intended CLI UX.Given how often this shows up, you might eventually want a small helper like
normalizeListOption<T>(value?: T[] | boolean): T[] | undefinedto cut down on repetition, but behavior here is fine.Also applies to: 469-511, 577-580, 929-985, 1921-1932, 1312-1515
lib/commands/databases.ts (1)
286-289: CLI argument edge case handling is correct but could use documentation.The pattern
(operations as unknown) === true ? [] : operationshandles the Commander.js edge case where variadic options passed without values may be coerced totrue. This is repeated throughout the file for all array parameters. Consider adding a brief inline comment explaining this behavior for future maintainers.lib/config.ts (1)
270-272: Type cast may be masking a missing property in interface.The cast
'endpoint' as keyof ProjectConfigDataforces TypeScript to acceptendpointas a valid key, butendpointdoesn't appear to be defined inProjectConfigData(based on the interface definition in types.ts). If the local config legitimately stores an endpoint, consider addingendpoint?: stringtoProjectConfigDatarather than using a type assertion.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (95)
.github/workflows/npm-publish.ymlCHANGELOG.mdREADME.mdindex.tsinstall.ps1install.shlib/client.tslib/commands/account.tslib/commands/console.tslib/commands/databases.tslib/commands/functions.tslib/commands/generic.tslib/commands/graphql.tslib/commands/health.tslib/commands/init.tslib/commands/locale.tslib/commands/messaging.tslib/commands/migrations.tslib/commands/project.tslib/commands/projects.tslib/commands/proxy.tslib/commands/pull.tslib/commands/push.tslib/commands/run.tslib/commands/sites.tslib/commands/storage.tslib/commands/tables-db.tslib/commands/teams.tslib/commands/tokens.tslib/commands/users.tslib/commands/vcs.tslib/config.tslib/emulation/docker.tslib/enums/adapter.tslib/enums/api-service.tslib/enums/api.tslib/enums/attribute-status.tslib/enums/auth-method.tslib/enums/authentication-factor.tslib/enums/authenticator-type.tslib/enums/browser.tslib/enums/build-runtime.tslib/enums/column-status.tslib/enums/compression.tslib/enums/console-resource-type.tslib/enums/credit-card.tslib/enums/database-type.tslib/enums/deployment-download-type.tslib/enums/deployment-status.tslib/enums/email-template-locale.tslib/enums/email-template-type.tslib/enums/execution-method.tslib/enums/execution-status.tslib/enums/execution-trigger.tslib/enums/flag.tslib/enums/framework.tslib/enums/health-antivirus-status.tslib/enums/health-check-status.tslib/enums/image-format.tslib/enums/image-gravity.tslib/enums/index-status.tslib/enums/index-type.tslib/enums/message-priority.tslib/enums/message-status.tslib/enums/messaging-provider-type.tslib/enums/name.tslib/enums/o-auth-provider.tslib/enums/output.tslib/enums/password-hash.tslib/enums/platform-type.tslib/enums/project-usage-range.tslib/enums/proxy-resource-type.tslib/enums/proxy-rule-deployment-resource-type.tslib/enums/proxy-rule-status.tslib/enums/region.tslib/enums/relation-mutate.tslib/enums/relationship-type.tslib/enums/runtime.tslib/enums/sms-template-locale.tslib/enums/sms-template-type.tslib/enums/smtp-encryption.tslib/enums/smtp-secure.tslib/enums/status-code.tslib/enums/template-reference-type.tslib/enums/theme.tslib/enums/timezone.tslib/enums/usage-range.tslib/enums/vcs-detection-type.tslib/enums/vcs-reference-type.tslib/paginate.tslib/parser.tslib/questions.tslib/types.tspackage.jsonscoop/appwrite.config.json
🧰 Additional context used
🧬 Code graph analysis (8)
lib/commands/init.ts (1)
lib/questions.ts (2)
questionsInitResources(773-788)questionsInitProject(152-268)
lib/commands/run.ts (1)
lib/questions.ts (1)
questionsRunFunctions(1017-1037)
lib/commands/pull.ts (1)
lib/questions.ts (1)
questionsPullResources(279-294)
lib/questions.ts (1)
lib/commands/generic.ts (1)
client(242-316)
lib/commands/generic.ts (1)
lib/config.ts (1)
globalConfig(858-858)
lib/commands/storage.ts (1)
lib/types.ts (2)
UploadProgress(27-33)FileInput(20-25)
lib/config.ts (1)
lib/types.ts (11)
Entity(39-42)ProjectConfigData(291-303)SiteConfig(261-278)FunctionConfig(242-259)CollectionConfig(179-188)TableConfig(218-227)BucketConfig(229-240)TopicConfig(285-289)TeamConfig(280-283)ProjectSettings(77-113)RawProjectSettings(115-143)
lib/commands/functions.ts (1)
lib/types.ts (2)
UploadProgress(27-33)FileInput(20-25)
🪛 actionlint (1.7.9)
.github/workflows/npm-publish.yml
9-9: could not parse as YAML: mapping values are not allowed in this context
(syntax-check)
🪛 LanguageTool
CHANGELOG.md
[style] ~5-~5: Consider using a synonym to be more concise.
Context: # Change Log ## 13.0.0-rc.2 * Fixes a lot of typescript errors throughout the codeba...
(A_LOT_OF)
🪛 YAMLlint (1.37.1)
.github/workflows/npm-publish.yml
[error] 9-9: syntax error: mapping values are not allowed here
(syntax)
🔇 Additional comments (114)
lib/enums/theme.ts (1)
1-4: LGTM!The Theme enum is correctly defined with appropriate TypeScript conventions and provides type-safe constants for theme selection.
lib/enums/message-priority.ts (1)
1-4: LGTM! The enum implementation is clean and follows TypeScript best practices with string values for serialization. Verified thatMessagePriorityis properly used inlib/commands/messaging.ts.lib/enums/execution-trigger.ts (1)
1-5: No changes needed. The enum correctly follows the established pattern in the codebase—all enums consistently use simple declarations without JSDoc documentation.lib/enums/browser.ts (1)
1-16: No changes needed. The browser code mappings forMicrosoftEdge = 'ps'andMicrosoftEdgeIOS = 'oi'are correct according to Appwrite SDK specifications and match the API requirements.lib/enums/health-check-status.ts (1)
1-4: LGTM!Clean enum declaration with appropriate values for health check status representation.
lib/enums/api.ts (1)
1-5: LGTM!Enum correctly represents the three API protocol types used in the system.
lib/enums/messaging-provider-type.ts (1)
1-5: LGTM!Enum appropriately represents the messaging provider types used in the system.
lib/enums/index-status.ts (1)
1-7: LGTM!Comprehensive enum covering the full lifecycle of database indexes, including transitional and error states.
lib/enums/authenticator-type.ts (1)
1-3: LGTM!Enum correctly defines the TOTP authenticator type. Note that this currently contains only one member, which may be expanded with additional authenticator types (e.g., WebAuthn, U2F) in future iterations.
lib/enums/vcs-detection-type.ts (1)
1-4: LGTM!Enum appropriately categorizes VCS detection modes for runtime and framework detection.
lib/enums/region.ts (1)
1-3: LGTM!Enum correctly defines the default region. Note that this currently contains only a single member, which may be expanded with additional regions (e.g., specific geographic regions) when multi-region support is implemented.
lib/enums/usage-range.ts (1)
1-5: LGTM! Clean enum definition for time range constants.The enum provides clear, type-safe constants for usage time windows that can be used across the codebase.
lib/commands/vcs.ts (1)
4-4: LGTM! Import modernization aligns with ES module standards.The migration from CommonJS (
require) to ES module imports is correct. The type-only imports forUploadProgressandFileInputare properly annotated, and theVCSDetectionTypeenum import is used appropriately in the interface definitions below.Also applies to: 14-15
lib/enums/api-service.ts (1)
1-15: LGTM! Centralized API service identifiers.The enum provides type-safe constants for API service names, improving maintainability and reducing typos across the codebase.
lib/enums/o-auth-provider.ts (1)
1-42: LGTM! Comprehensive OAuth provider enumeration.The enum covers a wide range of OAuth providers with a
Mockoption for testing. The naming conventions align with provider identifiers and maintain consistency with the backend API.lib/enums/authentication-factor.ts (1)
1-6: LGTM! Authentication factor constants defined.The enum provides type-safe constants for multi-factor authentication methods, maintaining consistency with backend API values.
lib/enums/proxy-rule-deployment-resource-type.ts (1)
1-4: LGTM! Clear resource type enumeration.The enum provides type-safe constants for proxy rule deployment resource types.
lib/enums/name.ts (1)
1-14: LGTM! Consistent versioned identifier enumeration.The enum provides centralized v1 resource identifiers with a clear and consistent naming pattern across all members.
lib/enums/column-status.ts (1)
1-7: LGTM! Comprehensive column lifecycle status enumeration.The enum provides type-safe constants for tracking column state throughout its lifecycle, from creation through deletion and error states.
lib/enums/template-reference-type.ts (1)
1-5: LGTM!Clean and idiomatic TypeScript string enum following consistent naming conventions.
lib/enums/relationship-type.ts (1)
1-6: LGTM!Standard relationship type enum with proper naming conventions.
lib/enums/attribute-status.ts (1)
1-7: LGTM!Well-defined status enum covering the attribute lifecycle states.
lib/enums/compression.ts (1)
1-5: LGTM!Clean enum covering standard compression options.
lib/enums/execution-status.ts (1)
1-7: LGTM!Comprehensive execution status enum covering all lifecycle states.
lib/enums/flag.ts (1)
1-197: LGTM!Comprehensive country flag enum with ISO 3166-1 alpha-2 codes. The ordering appears to be intentional (likely matching the upstream API spec).
lib/enums/relation-mutate.ts (1)
1-5: LGTM!The enum correctly defines database relation mutation strategies with appropriate string values that align with standard SQL/ORM conventions.
lib/enums/adapter.ts (1)
1-4: LGTM!Clean enum definition for adapter types with appropriate string values.
lib/enums/deployment-status.ts (1)
1-7: LGTM!The enum appropriately models the deployment lifecycle with clear, self-documenting state values.
lib/enums/runtime.ts (1)
1-69: Enum structure is correct.The Runtime enum provides comprehensive coverage of supported runtimes with appropriate version mappings.
lib/enums/proxy-rule-status.ts (1)
1-6: LGTM!The enum correctly models proxy rule verification states with clear, self-documenting values.
lib/enums/message-status.ts (1)
1-7: LGTM!The enum appropriately models the message lifecycle with clear state transitions from draft through processing, scheduling, and final delivery states.
lib/enums/status-code.ts (1)
1-6: No action required. The string representation of HTTP status codes in the StatusCode enum is consistent with all other enums in this codebase and is intentional for Appwrite API compatibility. The enum values are correctly passed to the API payload and function as designed.Likely an incorrect or invalid review comment.
lib/client.ts (4)
2-2: LGTM: File type import supports improved type safety.The addition of the
Filetype import from undici properly supports the type-safe file handling at line 171.
25-26: LGTM: Version updated consistently.SDK version correctly updated from rc.1 to rc.2 in both headers, matching the PR objectives.
171-171: LGTM: Removed unsafe type cast.Excellent improvement removing the
as anycast. With the properFiletype import, the code is now type-safe without requiring type assertions.
12-12: CHUNK_SIZE public exposure is intentional and necessary.The
CHUNK_SIZEconstant is accessed by external modules (lib/commands/functions.ts,lib/commands/storage.ts, andlib/commands/sites.ts) to manage file uploads in chunks. The public visibility is required for these modules to calculate buffer sizes, chunk boundaries, and upload progress.lib/enums/execution-method.ts (1)
1-9: LGTM: Well-defined HTTP method enum.The
ExecutionMethodenum provides type-safe constants for HTTP methods with appropriate member values.index.ts (1)
8-8: LGTM: Import modernization.The update from CommonJS to ES module import syntax for Commander aligns with modern TypeScript practices and the broader import standardization mentioned in the PR summary.
lib/enums/auth-method.ts (1)
1-9: LGTM: Comprehensive authentication method enum.The
AuthMethodenum provides well-defined authentication method constants with appropriate kebab-case string values.lib/enums/image-gravity.ts (1)
1-11: LGTM: Standard image gravity enum.The
ImageGravityenum provides complete coverage of standard image positioning options with consistent naming.lib/enums/platform-type.ts (1)
1-17: LGTM: Comprehensive platform type enum.The
PlatformTypeenum provides extensive coverage of supported platforms with consistent kebab-case naming.lib/enums/timezone.ts (1)
1-421: LGTM: Comprehensive IANA timezone enum.The
Timezoneenum provides extensive coverage of IANA timezone identifiers with proper lowercase formatting. This enables type-safe timezone selection across the codebase.lib/enums/credit-card.ts (1)
1-19: LGTM with verification needed for one value.The credit card enum provides comprehensive coverage of card brands. However, verify the spelling at line 13.
lib/enums/password-hash.ts (1)
1-14: LGTM!The enum provides a clean, type-safe set of password hash algorithm identifiers. The naming is consistent and the values are appropriate.
lib/enums/build-runtime.ts (1)
1-70: LGTM!Comprehensive enum covering a wide range of build runtimes with consistent naming conventions. This provides excellent type safety for runtime identifiers.
lib/parser.ts (1)
127-127: LGTM!Version string correctly updated to match the release candidate bump.
lib/commands/project.ts (1)
4-4: LGTM!Import modernization from CommonJS to ES modules and addition of type/enum imports improve type safety and align with modern TypeScript practices.
Also applies to: 14-15
README.md (1)
32-32: LGTM!Documentation correctly updated to reflect the version bump to 13.0.0-rc.2.
Also applies to: 63-63
lib/enums/vcs-reference-type.ts (1)
1-6: LGTM!Clean enum providing type-safe VCS reference type identifiers. The implementation is straightforward and correct.
lib/enums/console-resource-type.ts (1)
1-3: LGTM! Clean enum definition.The
ConsoleResourceTypeenum is properly defined and exported. It's correctly consumed bylib/commands/console.tsfor type-safe resource type handling.lib/commands/locale.ts (1)
4-4: ES module import modernization looks good.The migration from
require('ignore')toimport ignore from 'ignore'aligns with the broader ES module standardization across the codebase.package.json (2)
5-5: Version bump to 13.0.0-rc.2 looks good.The version increment aligns with the PR objectives and follows proper semantic versioning for release candidates.
17-17: Build passes successfully with the TypeScript compilation script.The build script
"build": "tsc"executes without errors and enforces strict TypeScript compilation. Note that this is a newly created configuration rather than a modification of an existing script—the git history does not show any prior|| truefallback being removed.Likely an incorrect or invalid review comment.
lib/enums/smtp-encryption.ts (1)
1-5: LGTM! Well-defined SMTP encryption enum.The
SmtpEncryptionenum properly defines standard SMTP encryption options (none, SSL, TLS) with appropriate string values.lib/enums/index-type.ts (1)
1-6: LGTM! Comprehensive database index type enum.The
IndexTypeenum correctly defines all standard database index types (key, fulltext, unique, spatial) and provides type-safe constants for index-related operations.lib/enums/deployment-download-type.ts (1)
1-4: LGTM! Clear deployment download type enum.The
DeploymentDownloadTypeenum appropriately defines the two deployment artifact types (source and output) for download operations.lib/commands/health.ts (2)
4-4: ES module import modernization approved.The migration to ES module syntax for the
ignorepackage is consistent with the broader modernization effort across the codebase.
14-15: Remove unused type importsUploadProgressandFileInput.The
Nameenum import is correctly used inHealthGetFailedJobsRequestParams(line 305). However,UploadProgressandFileInputare not referenced anywhere in the file and should be removed.Likely an incorrect or invalid review comment.
lib/commands/console.ts (2)
4-4: ES module import looks good.The standardized ES module import for the
ignorepackage aligns with the modernization goals of this release.
14-15: Remove unused type importsUploadProgressandFileInput.The
ConsoleResourceTypeenum import is correctly used inConsoleGetResourceRequestParams(line 42). However,UploadProgressandFileInputare not used anywhere in this file and should be removed.Likely an incorrect or invalid review comment.
lib/commands/tokens.ts (1)
4-4: LGTM - ES module import modernization.The switch from CommonJS
requireto ES module default import aligns with the codebase modernization effort in this PR.lib/commands/pull.ts (1)
57-57: LGTM - Consistent array syntax for inquirer.prompt.Wrapping the question in an array is more explicit and aligns with the function signature. Both forms work, but using an array is the conventional approach when prompting, even for a single question.
lib/enums/smtp-secure.ts (1)
1-4: LGTM - New type-safe enum for SMTP security modes.The enum provides a clear, type-safe way to specify SMTP security protocols. The distinction from
SmtpEncryption(which includes aNoneoption) is appropriate for contexts where security is mandatory.install.sh (1)
99-99: LGTM - Version bump to 13.0.0-rc.2.The version update aligns with the PR objective for the CLI SDK update.
lib/commands/proxy.ts (2)
4-4: LGTM - ES module import modernization.Consistent with the codebase-wide import style update.
14-16: Enum imports are properly utilized; type imports are unused.
StatusCodeandProxyResourceTypeare correctly used in theProxyCreateRedirectRuleRequestParamsinterface (lines 146-148). However,UploadProgressandFileInputare imported but not used in this file.lib/commands/account.ts (2)
4-4: LGTM - ES module import modernization.Consistent with the codebase-wide import style update.
15-17: LGTM - Enum imports are properly utilized.
AuthenticatorType,AuthenticationFactor, andOAuthProviderare correctly used in their respective interface definitions throughout the file.lib/enums/project-usage-range.ts (1)
1-4: LGTM - New type-safe enum for project usage ranges.Clean enum definition providing type safety for specifying usage data time ranges.
lib/enums/sms-template-locale.ts (1)
1-133: LGTM - Comprehensive SMS template locale enum.The enum provides a type-safe representation of supported SMS template locales with good coverage of regional variants.
Minor note: Line 123 uses
'ua'for Ukrainian, which is the country code (Ukraine) rather than the ISO 639-1 language code ('uk'). This is likely intentional to match the Appwrite API specification.scoop/appwrite.config.json (1)
3-3: LGTM!Version bump from 13.0.0-rc.1 to 13.0.0-rc.2 is consistent across all references.
Also applies to: 9-9, 18-18
lib/commands/graphql.ts (1)
4-4: LGTM!Import style modernization to ES module default import is consistent with the broader refactoring effort across the codebase.
lib/commands/init.ts (1)
44-44: LGTM!Wrapping single-question prompts in arrays improves consistency with the
inquirer.prompt()API usage across the codebase.Also applies to: 88-90
lib/commands/run.ts (2)
4-4: LGTM!Import style modernization and
ignore()instantiation updates are consistent with ES module patterns. The array wrapping forinquirer.prompt()aligns with the broader codebase refactoring.Also applies to: 31-31, 193-193, 258-258
250-256: No changes needed. The tar library (v6.1.11) automatically detects and decompresses gzipped archives on extraction, making the explicitgzip: trueoption unnecessary. The pattern of omitting the gzip option intar.extract()while using it intar.create()is correct and intentional—you explicitly compress when creating, but rely on auto-detection when extracting. This pattern is consistent throughout the codebase.lib/emulation/docker.ts (1)
1-1: LGTM!Import modernization and type centralization improve code organization. Moving
FunctionConfigto a central types file enhances reusability across the codebase.Also applies to: 11-11, 54-54
install.ps1 (1)
16-17: LGTM!Download URL updates to version 13.0.0-rc.2 are consistent with the release candidate bump across the project.
lib/commands/users.ts (2)
4-18: LGTM – Import modernization and new type definitions.The ES module import style for
ignoreand the addition of typed imports (UploadProgress,FileInput, and enums) align with the broader SDK update for version 13.0.0-rc.2.
675-675: Boolean-to-empty-array normalization looks correct.This pattern handles the CLI edge case where
--labelswithout a value becomestrue. The cast throughunknownproperly bypasses TypeScript's type narrowing.lib/commands/generic.ts (3)
55-57: LGTM – Session now stores endpoint for better multi-account support.Storing the endpoint with the session enables proper handling of multiple accounts across different Appwrite instances.
282-288: LGTM – Typed health check response and session storage.The generic type parameter on
client.call<{ version?: string }>provides type safety, and the session correctly stores the endpoint.
323-324: LGTM – Explicit string casts for legacy migration.The
as stringcasts are appropriate here since the precedinghas()checks guarantee the values exist, and the legacy config stored these as strings.lib/commands/projects.ts (6)
4-25: LGTM – Import updates align with SDK modernization.The ES module import for
ignoreand the addition of typed enum imports (Region,Api,AuthMethod,OAuthProvider,PlatformType,ApiService,SMTPSecure,EmailTemplateType,EmailTemplateLocale,SmsTemplateType,SmsTemplateLocale) provide better type safety.
482-498: LGTM – Consistent boolean-to-array normalization fornumbers.The pattern
(numbers as unknown) === true ? [] : numberscorrectly handles the CLI edge case, consistent with other commands in this PR.
869-872: LGTM – Boolean-to-array normalization forscopesinprojectsCreateJWT.
942-945: LGTM – Consistent normalization pattern forscopesin key creation/update.Also applies to: 1013-1016
1431-1434: LGTM – Boolean-to-array normalization foremailsin SMTP test.
1752-1755: LGTM – Boolean-to-array normalization foreventsin webhook create/update.Also applies to: 1839-1842
lib/enums/email-template-locale.ts (1)
1-134: LGTM – Comprehensive locale enum for email templates.The
EmailTemplateLocaleenum provides type-safe constants for all supported locales, using BCP 47-style string values. The coverage is extensive and aligns with internationalization best practices.lib/commands/migrations.ts (4)
4-14: LGTM – Import modernization for migrations module.ES module import for
ignoreand type-only imports forUploadProgressandFileInputalign with the SDK update.
90-93: LGTM – Boolean-to-array normalization forresourcesin Appwrite migration.
183-190: LGTM – Boolean-to-array normalization forcolumnsandqueriesin CSV export.
274-277: LGTM – Consistent normalization forresourcesacross Firebase, NHost, and Supabase migrations.Also applies to: 346-349, 459-462
lib/commands/teams.ts (2)
4-14: LGTM – Import modernization for teams module.ES module import for
ignoreand type-only imports align with the SDK update.
100-103: LGTM – Consistent boolean-to-array normalization forroles.The pattern correctly handles CLI edge cases across
teamsCreate,teamsCreateMembership, andteamsUpdateMembership.Also applies to: 301-304, 365-368
lib/commands/messaging.ts (1)
4-4: Imports and enum usage look consistentUsing the default
ignoreimport plusMessagePriorityandSmtpEncryptionenums matches the rest of the codebase’s style; no issues spotted here.Also applies to: 14-16
lib/paginate.ts (1)
5-21: Paginate overloads and return union align with existing usageThe new overloads (array vs. wrapped-object + total) match the implementation and the way callers destructure results (
{ attributes },{ databases }, etc.). The pagination loop and termination conditions are unchanged, so behavior should remain consistent.Also applies to: 24-31, 69-76
lib/commands/push.ts (1)
95-96: Enum-typing for project services and auth methods is a solid tighteningPassing
serviceandmethodthrough theApiServiceandAuthMethodenums improves type safety without changing what’s actually sent over the wire. No behavioral issues noted.Also applies to: 1080-1088, 1104-1113
lib/questions.ts (2)
34-43: ExtendingQuestion.choicesto acceptstring[]matches actual usageMany questions use simple string arrays for choices; adding
string[]to thechoicestype definition makes those patterns type-correct without affecting runtime behavior.
248-267: Typed region and endpoint validation calls are straightforwardUsing minimally-typed responses for
/console/regionsand/health/versionclarifies the expected payload (regions/version) while preserving existing error messages and control flow.Also applies to: 702-723
lib/commands/storage.ts (1)
14-18: Enum-typing for compression, image, and usage parameters is appropriateUsing
Compression,ImageGravity,ImageFormat, andUsageRangefor the respective request params makes the allowable values explicit and matches the CLI help text for these options. No behavioral concerns here.Also applies to: 588-646, 716-760
lib/commands/sites.ts (1)
4-21: Imports and enum typing for sites look consistentThe switch to
import ignore from 'ignore'and the addition ofUploadProgress,FileInput, and the various enum imports are coherent with the new shared typing model and don’t introduce any obvious issues.lib/commands/functions.ts (1)
4-20: New imports and enums align with shared typesThe introduction of
ignoreas a default import and the additional type/enum imports (UploadProgress,FileInput,Runtime,UsageRange,TemplateReferenceType,VCSReferenceType,DeploymentDownloadType,ExecutionMethod) fit the broader typing refactor and don’t present functional issues.lib/types.ts (1)
1-4: New shared types and config schemas look coherentThe additions and adjustments here—
ResponseType,FileUploadnow usingFile, the newFileInputandUploadProgressinterfaces, helper types (Entity,ParsedData,CommandDescription,CliConfig), as well as the expanded config models (ProjectSettings,RawProjectSettings,DatabaseConfig/CollectionConfig/TableConfig/ColumnConfig/TableIndexConfig,FunctionConfig,SiteConfig, and the updatedProjectConfigData)—are internally consistent and match how the commands are now consuming them.They should make the rest of the codebase’s typing around uploads, progress reporting, and project configuration more explicit without introducing runtime risk.
Also applies to: 14-33, 39-60, 69-76, 77-113, 115-149, 151-177, 190-227, 242-259, 261-303
lib/commands/databases.ts (4)
4-18: LGTM! Import modernization and type additions.The switch to ES module import for
ignoreand the addition of typed imports forUploadProgress,FileInput, and enums improves type safety and consistency across the codebase.
1896-1906: Type change fromobjecttostringaligns with CLI input model.The change from
data: objecttodata: stringcorrectly reflects that CLI users pass JSON as string arguments. The subsequentJSON.parse(data)converts it to an object for the API call.
2418-2429: LGTM!Consistent application of the array fallback pattern for index creation parameters.
1955-1958: Pattern inconsistency: Single document function parses JSON, batch operations do not.The
databasesCreateDocumentfunction parses itsdataparameter withJSON.parse(data)before sending it to the API. However,databasesCreateDocumentsanddatabasesUpsertDocumentsacceptdocuments: string[]and pass it directly to the payload without parsing. Both use the same API endpoint. Verify whether each document string in the array should be individually parsed, or if the API handles string deserialization internally.lib/config.ts (6)
6-21: LGTM! Comprehensive type imports improve type safety.The expanded type imports from
./typesprovide proper typing for all configuration entities used throughout the file. This is a significant improvement over the previousanyusage.
120-121: Good change:readonlymodifier for immutable property.Changing
pathfromprotectedtoreadonlycorrectly expresses that this property should not be modified after construction.
183-227: Improved typing for database entity methods.Using the
Entitytype instead ofanyprovides better type safety. The type casts forthis.setare a reasonable workaround for TypeScript's strict generic constraints when dealing with dynamic entity types.
278-323: LGTM! Strongly typed config accessors.The typed getter/setter methods using
SiteConfig,FunctionConfig, etc., provide excellent type safety. The return type patternTypeConfig | Record<string, never>correctly represents that either a valid config object or an empty object is returned.
606-670: Well-structured settings transformation.The
createSettingsObjectmethod cleanly transforms the flatRawProjectSettingsfrom the API into the nestedProjectSettingsstructure. This separation provides a better developer experience while handling API compatibility internally.
676-695: LGTM! Const assertions improve type safety.Using
as constfor static preference keys provides literal types instead ofstring, enabling better type checking. Thereadonlymodifier onIGNORE_ATTRIBUTESprevents accidental mutation of the array.
| permissions: | ||
| id-token: write | ||
| contents: read |
There was a problem hiding this comment.
Fix YAML indentation syntax error.
The permissions block has inconsistent indentation. Line 8 (id-token: write) is missing proper indentation, causing a YAML syntax error that will prevent the workflow from executing.
🔎 Proposed fix
permissions:
-id-token: write
+ id-token: write
contents: read📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| permissions: | |
| id-token: write | |
| contents: read | |
| permissions: | |
| id-token: write | |
| contents: read |
🧰 Tools
🪛 actionlint (1.7.9)
9-9: could not parse as YAML: mapping values are not allowed in this context
(syntax-check)
🪛 YAMLlint (1.37.1)
[error] 9-9: syntax error: mapping values are not allowed here
(syntax)
🤖 Prompt for AI Agents
In .github/workflows/npm-publish.yml around lines 7 to 9, the permissions block
has incorrect indentation (line 8 'id-token: write' is not indented to align
under permissions), causing a YAML syntax error; fix by indenting the keys under
permissions consistently (make 'id-token: write' and 'contents: read' children
of 'permissions') so the permissions block is valid YAML.
| if (typeof data !== 'undefined') { | ||
| payload['data'] = JSON.parse(data); | ||
| } |
There was a problem hiding this comment.
Add error handling for JSON.parse to improve CLI UX.
JSON.parse(data) can throw a SyntaxError if the user provides malformed JSON. This would result in an unhandled exception with a cryptic error message. Consider wrapping in try-catch with a user-friendly error message.
This same pattern appears at lines 2029, 2146, and 2187.
🔎 Proposed fix
if (typeof data !== 'undefined') {
- payload['data'] = JSON.parse(data);
+ try {
+ payload['data'] = JSON.parse(data);
+ } catch (e) {
+ throw new Error(`Invalid JSON provided for --data: ${(e as Error).message}`);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (typeof data !== 'undefined') { | |
| payload['data'] = JSON.parse(data); | |
| } | |
| if (typeof data !== 'undefined') { | |
| try { | |
| payload['data'] = JSON.parse(data); | |
| } catch (e) { | |
| throw new Error(`Invalid JSON provided for --data: ${(e as Error).message}`); | |
| } | |
| } |
🤖 Prompt for AI Agents
In lib/commands/databases.ts around lines 1916-1918, calling JSON.parse(data)
can throw on malformed JSON; wrap the parse in a try/catch, validate that data
is non-empty, and on failure print a clear user-facing error (e.g., "Invalid
JSON for --data: <error message>") and exit with a non-zero code or return a
rejected Promise so the CLI fails gracefully. Apply the same change to the
identical patterns at lines ~2029, ~2146, and ~2187 so all user-provided JSON is
safely parsed with consistent, friendly error handling.
|
|
||
| interface GraphqlQueryRequestParams { | ||
| query: object; | ||
| query: string; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
head -100 lib/commands/graphql.ts | cat -nRepository: appwrite/sdk-for-cli
Length of output: 3561
🏁 Script executed:
# Run the provided search for usages
rg -nP --type=ts -C3 '\b(graphqlQuery|graphqlMutation)\s*\(' -g '!lib/commands/graphql.ts'Repository: appwrite/sdk-for-cli
Length of output: 46
🏁 Script executed:
# Also search for JSON.parse usage in the graphql.ts file
rg -nP --type=ts 'JSON\.parse' lib/commands/graphql.tsRepository: appwrite/sdk-for-cli
Length of output: 161
🏁 Script executed:
rg -nP --type=ts 'graphqlQuery|graphqlMutation' lib/commands/graphql.ts | head -20Repository: appwrite/sdk-for-cli
Length of output: 466
🏁 Script executed:
# Search for usages of graphqlQuery and graphqlMutation in other files
rg -nP --type=ts '(graphqlQuery|graphqlMutation)' --max-count=50Repository: appwrite/sdk-for-cli
Length of output: 562
🏁 Script executed:
rg -nP --type=ts 'actionRunner' lib/parser.ts -A 20 | head -50Repository: appwrite/sdk-for-cli
Length of output: 949
🏁 Script executed:
# Also check if there's any validation of query parameter before it's passed
rg -nP --type=ts 'query.*valid|validate.*query' -g '!node_modules'Repository: appwrite/sdk-for-cli
Length of output: 4212
🏁 Script executed:
rg -nP --type=ts 'parseError' lib/parser.ts -B 5 -A 10Repository: appwrite/sdk-for-cli
Length of output: 1282
🏁 Script executed:
# Let's look at the full context of how these functions are called through the CLI
rg -nP --type=ts 'graphql.*query|graphql.*mutation' lib/commands/graphql.ts -A 5 | head -30Repository: appwrite/sdk-for-cli
Length of output: 777
Add error handling for JSON.parse operations to provide clearer error messages.
The query parameter type is string, and JSON.parse(query) is called at lines 52 and 82 without explicit error handling. While errors are caught at the actionRunner level, they will surface as generic JSON SyntaxError messages. Consider wrapping the JSON.parse() calls in try-catch blocks to provide more user-friendly error messages, e.g., "Invalid JSON format in query parameter."
🤖 Prompt for AI Agents
In lib/commands/graphql.ts around line 40 (and specifically where JSON.parse is
used at ~lines 52 and 82), the code calls JSON.parse(query) without local error
handling; wrap each JSON.parse(...) in a try-catch and on failure throw a new,
descriptive Error (for example: "Invalid JSON format in query parameter:
<originalError.message>") or return a user-friendly error so callers receive a
clear message instead of a generic SyntaxError; preserve the original error
message for debugging and keep stack trace by rethrowing a new Error that
includes the original.message.
| JCB = 'jcb', | ||
| Mastercard = 'mastercard', | ||
| Naranja = 'naranja', | ||
| TarjetaShopping = 'targeta-shopping', |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd /tmp && find . -type f -name "credit-card.ts" 2>/dev/null | head -20Repository: appwrite/sdk-for-cli
Length of output: 46
🏁 Script executed:
rg "targeta-shopping|tarjeta-shopping" --type ts --type jsRepository: appwrite/sdk-for-cli
Length of output: 130
🏁 Script executed:
cat -n lib/enums/credit-card.tsRepository: appwrite/sdk-for-cli
Length of output: 662
🌐 Web query:
Tarjeta Shopping credit card identifier payment API official spelling
💡 Result:
- Official name (brand): "Tarjeta Shopping".
- Common payment-API identifier (used by MercadoPago / MercadoLibre APIs): tarshop. [1][2]
Sources:
[1] MercadoPago / MercadoLibre developers — payment methods list (shows id "tarshop", name "Tarjeta Shopping").
[2] Nuvei APM page listing "Tarjeta Shopping".
Fix spelling: 'targeta-shopping' should be 'tarjeta-shopping'.
The enum value contains a typo. The correct Spanish spelling is "tarjeta" (meaning "card"), which matches the official brand name "Tarjeta Shopping" and your enum name TarjetaShopping. Change 'targeta-shopping' to 'tarjeta-shopping'.
🤖 Prompt for AI Agents
In lib/enums/credit-card.ts around line 13, the enum value string has a typo:
replace 'targeta-shopping' with the correct spelling 'tarjeta-shopping' so the
exported enum value matches the enum key TarjetaShopping and the official brand
name.
| export enum ImageFormat { | ||
| Jpg = 'jpg', | ||
| Jpeg = 'jpeg', | ||
| Png = 'png', | ||
| Webp = 'webp', | ||
| Heic = 'heic', | ||
| Avif = 'avif', | ||
| Gif = 'gif', | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check for duplicate enum definitions and their usage patterns
# Find the Output enum definition
echo "=== Output enum definition ==="
fd -e ts -e js output.ts lib/enums/ --exec cat {}
echo -e "\n=== ImageFormat usage ==="
rg -n --type=ts "ImageFormat\." -C 2
echo -e "\n=== Output enum usage ==="
rg -n --type=ts "Output\.(Jpg|Jpeg|Png|Webp|Heic|Avif|Gif)" -C 2Repository: appwrite/sdk-for-cli
Length of output: 299
Remove duplicate enum or consolidate usage.
Verification confirms that ImageFormat and Output enums are identical in structure and mappings. Additionally, neither enum is currently used in the codebase. This represents unintentional duplication and dead code. Either remove the ImageFormat enum if Output is the canonical version, or consolidate to a single enum and update any future usage to reference only that enum.
🤖 Prompt for AI Agents
In lib/enums/image-format.ts lines 1-9 the ImageFormat enum duplicates the
Output enum elsewhere and is unused; remove this duplication by deleting
ImageFormat and consolidating to the canonical Output enum (or replace
ImageFormat with a re-export/alias pointing to Output if backward compatibility
is needed), update any imports to reference the single enum (export from the
canonical file), and run TypeScript compile/tests to ensure no remaining
references to ImageFormat remain.
| export enum ProxyResourceType { | ||
| Site = 'site', | ||
| Function = 'function', | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find both enum files and compare their contents
echo "=== Searching for proxy-related enum files ==="
fd -e ts 'proxy.*resource.*type' lib/enums/
echo -e "\n=== Checking ProxyResourceType ==="
cat lib/enums/proxy-resource-type.ts 2>/dev/null || echo "File not found"
echo -e "\n=== Checking ProxyRuleDeploymentResourceType ==="
cat lib/enums/proxy-rule-deployment-resource-type.ts 2>/dev/null || echo "File not found"Repository: appwrite/sdk-for-cli
Length of output: 454
🏁 Script executed:
#!/bin/bash
# Search for imports and usages of both enums
echo "=== Usages of ProxyResourceType ==="
rg 'ProxyResourceType' --type ts -A 2 -B 2
echo -e "\n=== Usages of ProxyRuleDeploymentResourceType ==="
rg 'ProxyRuleDeploymentResourceType' --type ts -A 2 -B 2Repository: appwrite/sdk-for-cli
Length of output: 1203
Remove the unused ProxyRuleDeploymentResourceType enum or consolidate with ProxyResourceType.
ProxyRuleDeploymentResourceType has identical members (Site = 'site', Function = 'function') and is not used anywhere in the codebase. ProxyResourceType is the active enum used in lib/commands/proxy.ts. Remove the duplicate or consolidate both into a single enum if they were intended to coexist.
🤖 Prompt for AI Agents
In lib/enums/proxy-resource-type.ts lines 1-4: there is a duplicate enum
situation — remove the unused ProxyRuleDeploymentResourceType (or consolidate
it) so only the active ProxyResourceType remains; search the codebase for any
references to ProxyRuleDeploymentResourceType and either replace them with
ProxyResourceType if intended to be the same, or delete the unused enum
file/definition; ensure imports are updated and run a type-check to confirm no
references remain.
This PR contains updates to the Command Line SDK for version 13.0.0-rc.2.
Summary by CodeRabbit
New Features
Improvements
Chores
✏️ Tip: You can customize this high-level summary in your review settings.