fix(sites): stop reading the framework start command - #3156
Conversation
The create-site flows read startCommand off a framework adapter and offered it as a prefilled value and a placeholder. The API never returns that field - FrameworkAdapter does not declare it - so the reads always resolved to undefined, and the cast that made them typecheck was the only thing hiding it. Had the field ever been returned, the console would have put an internal runtime command in front of every user creating a site. Drop the field from the create flows entirely and let the server pick its own default. In site settings the input stays, but it moves under a collapsed Advanced section, loses the Reset-to-default button that had nothing to reset to, and takes a generic placeholder.
Console (appwrite/console)Project ID: Tip Our Discord community has grown to 24K developers, and counting |
Greptile SummaryThe PR removes unsupported framework start-command defaults from site creation and moves the stored command into an advanced settings section.
Confidence Score: 4/5The PR is not yet safe to merge because adapter transitions after a framework change can restore and submit the previous framework's incompatible start command. The attempted fix clears the command on the initial framework change, but the later adapter-change branch restores site.startCommand solely by matching the original adapter key, leaving the previously reported stale-command failure reachable. Files Needing Attention: src/routes/(console)/project-[region]-[project]/sites/site-[site]/settings/updateBuildSettings.svelte Important Files Changed
Prompt To Fix All With AI### Issue 1
src/routes/(console)/project-[region]-[project]/sites/site-[site]/settings/updateBuildSettings.svelte:114
**Old start command gets restored**
When an SSR site is changed to another framework and its adapter is then changed away from and back to SSR, this branch restores `site.startCommand` solely because the adapter key matches the original adapter. The subsequent update submits the old framework's command for the newly selected framework, causing deployments to use an incompatible entrypoint.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (3): Last reviewed commit: "Clear the start command when the framewo..." | Re-trigger Greptile |
A start command names an entrypoint belonging to one framework. Carrying it across a switch submits it against a runtime that has no such entrypoint, and a switch to static leaves a command the form no longer shows. Reset it alongside the other framework-derived fields, and send it only for the ssr adapter, matching the fallbackFile line beside it.
| fallback = isOriginalAdapter | ||
| ? (site?.fallbackFile ?? data.fallbackFile) | ||
| : data.fallbackFile; | ||
| startCommand = isOriginalAdapter ? (site?.startCommand ?? '') : ''; |
There was a problem hiding this comment.
Old start command gets restored
When an SSR site is changed to another framework and its adapter is then changed away from and back to SSR, this branch restores site.startCommand solely because the adapter key matches the original adapter. The subsequent update submits the old framework's command for the newly selected framework, causing deployments to use an incompatible entrypoint.
Knowledge Base Used: Functions and Sites
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/routes/(console)/project-[region]-[project]/sites/site-[site]/settings/updateBuildSettings.svelte
Line: 114
Comment:
**Old start command gets restored**
When an SSR site is changed to another framework and its adapter is then changed away from and back to SSR, this branch restores `site.startCommand` solely because the adapter key matches the original adapter. The subsequent update submits the old framework's command for the newly selected framework, causing deployments to use an incompatible entrypoint.
**Knowledge Base Used:** [Functions and Sites](https://app.greptile.com/appwrite/-/custom-context/knowledge-base/appwrite/console/-/docs/project-functions-sites.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
What
The UI is unchanged. This removes the code that read
startCommandoff a framework adapter — a field the SDK never declared and the API no longer sends — plus a bug where a start command survived a framework change.Pairs with appwrite/appwrite#13194, which stops
listFrameworksshipping the internal command. No SDK regeneration needed:Models.FrameworkAdapteralready declares exactlykey,installCommand,buildCommand,outputDirectory,fallbackFile, which is what the endpoint now returns.The dead reads
src/lib/stores/sites.tsdeclared:Every create flow cast the adapter to that type and used
adapter.startCommandto prefill the input and fill the placeholder. Once the API stops sending it, all of those resolve toundefined— the prefill silently does nothing and Reset restores a value that does not exist. Gone, along with the cast.The bug
Changing framework or adapter kept the previous framework's start command in state, and
update()submitted it against the new runtime. PreviouslystartCommand = data.startCommandmasked this by resetting the field from adapter data; removing that read exposed it.ssradapter, matching thefallbackFileline beside itNot included
The earlier revision of this PR hid the field in the create flows and moved it under an Advanced section in settings. Dropped per Eldad — the UI stays exactly as it is.
Verification
npm run check— 0 errors, 87 warnings (all pre-existing). Prettier clean.