feat: SDK update for version 22.5.0#336
Conversation
ChiragAgg5k
changed the title
Greptile SummaryThis is the CLI SDK release for Appwrite version 22.5.0, adding new commands across several services and bumping the
Confidence Score: 3/5Safe to merge for the command additions, but publishing to npm with an RC pre-release dependency means every end-user install will pull in that RC — if it is deprecated or removed before a stable pin is committed, installs of the published package will break. The bulk of the change is generated SDK surface (new CLI commands, option additions, one removal) and looks correct. The
Important Files Changed
Prompt To Fix All With AIFix the following 3 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 3
package.json:54
**RC pre-release pinned as production dependency**
`@appwrite.io/console` is pinned to `15.3.0-rc.1`, a pre-release release candidate, without a caret. When `appwrite-cli@22.5.0` is published to npm, every `npm install appwrite-cli` will pull in this RC. If `15.3.0-rc.1` is deprecated, unpublished, or yanked before a stable version is pinned here, fresh installs of `22.5.0` will fail. And since there is no caret, a final `15.3.0` GA release will not be picked up automatically — the lockfile and `package.json` would need a manual bump.
### Issue 2 of 3
lib/utils.ts:354-356
**Network timeout shared with CLI command timeout**
`AbortSignal.timeout(options.timeoutMs ?? DEFAULT_HOMEBREW_COMMAND_TIMEOUT_MS)` reuses the Homebrew CLI execution timeout for an outbound network request to GitHub. The defaults for a CLI subprocess call and a GitHub raw-content fetch are often very different — network latency on slow connections could exhaust a timeout that was calibrated for a local process, causing the version check to silently fall through more often than intended. Consider a dedicated, shorter timeout constant (e.g. 3–5 s) for the remote fetch.
### Issue 3 of 3
.github/workflows/publish.yml:146-151
**Lock-drift check may produce false failures across npm versions**
`npm install --package-lock-only` regenerates `package-lock.json` using the npm version present on the runner. If CI uses a different npm version than the one used to commit the lockfile (e.g. a developer on npm 10 vs the runner on npm 9 or vice-versa), the regenerated lockfile will differ in formatting or resolved fields and `git diff --exit-code` will fail — blocking the publish even when there is no real drift. Pinning the npm version in this step (e.g. `npm install -g npm@<version>`) or documenting the exact required npm version would avoid spurious failures.
Reviews (1): Last reviewed commit: "(build): pin @appwrite.io/console to 15...." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| }, | ||
| "dependencies": { | ||
| "@appwrite.io/console": "^15.1.1", | ||
| "@appwrite.io/console": "15.3.0-rc.1", |
There was a problem hiding this comment.
@appwrite.io/console is pinned to 15.3.0-rc.1, a pre-release release candidate, without a caret. When appwrite-cli@22.5.0 is published to npm, every npm install appwrite-cli will pull in this RC. If 15.3.0-rc.1 is deprecated, unpublished, or yanked before a stable version is pinned here, fresh installs of 22.5.0 will fail. And since there is no caret, a final 15.3.0 GA release will not be picked up automatically — the lockfile and package.json would need a manual bump.
Prompt To Fix With AI
This is a comment left during a code review.
Path: package.json
Line: 54
Comment:
**RC pre-release pinned as production dependency**
`@appwrite.io/console` is pinned to `15.3.0-rc.1`, a pre-release release candidate, without a caret. When `appwrite-cli@22.5.0` is published to npm, every `npm install appwrite-cli` will pull in this RC. If `15.3.0-rc.1` is deprecated, unpublished, or yanked before a stable version is pinned here, fresh installs of `22.5.0` will fail. And since there is no caret, a final `15.3.0` GA release will not be picked up automatically — the lockfile and `package.json` would need a manual bump.
How can I resolve this? If you propose a fix, please make it concise.
| const signal = AbortSignal.timeout( | ||
| options.timeoutMs ?? DEFAULT_HOMEBREW_COMMAND_TIMEOUT_MS, | ||
| ); |
There was a problem hiding this comment.
AbortSignal.timeout(options.timeoutMs ?? DEFAULT_HOMEBREW_COMMAND_TIMEOUT_MS) reuses the Homebrew CLI execution timeout for an outbound network request to GitHub. The defaults for a CLI subprocess call and a GitHub raw-content fetch are often very different — network latency on slow connections could exhaust a timeout that was calibrated for a local process, causing the version check to silently fall through more often than intended. Consider a dedicated, shorter timeout constant (e.g. 3–5 s) for the remote fetch.
Prompt To Fix With AI
This is a comment left during a code review.
Path: lib/utils.ts
Line: 354-356
Comment:
**Network timeout shared with CLI command timeout**
`AbortSignal.timeout(options.timeoutMs ?? DEFAULT_HOMEBREW_COMMAND_TIMEOUT_MS)` reuses the Homebrew CLI execution timeout for an outbound network request to GitHub. The defaults for a CLI subprocess call and a GitHub raw-content fetch are often very different — network latency on slow connections could exhaust a timeout that was calibrated for a local process, causing the version check to silently fall through more often than intended. Consider a dedicated, shorter timeout constant (e.g. 3–5 s) for the remote fetch.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| run: | | ||
| # CLI builds with Bun, but npm audit reads package-lock.json. | ||
| # update-lockfiles.sh updates both lockfiles; this catches npm lock drift. | ||
| npm install --package-lock-only --ignore-scripts | ||
| git diff --exit-code package-lock.json | ||
| npm audit --audit-level=high --omit=dev |
There was a problem hiding this comment.
npm install --package-lock-only regenerates package-lock.json using the npm version present on the runner. If CI uses a different npm version than the one used to commit the lockfile (e.g. a developer on npm 10 vs the runner on npm 9 or vice-versa), the regenerated lockfile will differ in formatting or resolved fields and git diff --exit-code will fail — blocking the publish even when there is no real drift. Pinning the npm version in this step (e.g. npm install -g npm@<version>) or documenting the exact required npm version would avoid spurious failures.
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/publish.yml
Line: 146-151
Comment:
**Lock-drift check may produce false failures across npm versions**
`npm install --package-lock-only` regenerates `package-lock.json` using the npm version present on the runner. If CI uses a different npm version than the one used to commit the lockfile (e.g. a developer on npm 10 vs the runner on npm 9 or vice-versa), the regenerated lockfile will differ in formatting or resolved fields and `git diff --exit-code` will fail — blocking the publish even when there is no real drift. Pinning the npm version in this step (e.g. `npm install -g npm@<version>`) or documenting the exact required npm version would avoid spurious failures.
How can I resolve this? If you propose a fix, please make it concise.
2 participants
This PR contains updates to the SDK for version 22.5.0.
Built against
@appwrite.io/console@15.3.0-rc.1(preview published frompreview-1.9.x-rcunder thenextnpm tag).What's Changed
tablesdb createnow takes--specificationinstead of--dedicated-database-idhealth get-queue-logscommandnotificationscommand group for console notificationsorganization get,update, anddeletecommandsorganization list-memberships,create-membership,get-membership,update-membership, anddelete-membershipcommandstablesdb list-migrations,create-migration,get-migration, anddelete-migrationcommands for dedicated database migrationsoauth2 create-par,list-organizations, andlist-projectscommands--request-_urioption onoauth2 authorize; client ID, redirect URI, and response type are now optionalprojects list-addons,get-addon,delete-addon,confirm-addon-payment, andget-addon-pricecommandscreate-premium-geo-db-addoncommand onprojectsandorganizationsaccount list-logs,teams list-logs, andusers list-logscommandshealth get-geoandget-geo-premiumcommands--new-specificationoption onbackups create-restoration--promptand--max-ageoptions onproject update-o-auth-2-oidcX-Appwrite-Projectheader, fixing 401 errors for guest sessions