Repository navigation
Conversation
…files and a Pages functions directory When no framework is detected and a functions directory exists, autoconfig asks whether the project is a Cloudflare Pages project. Non-interactive runs (CI and coding agents) assume it is not and carry on as a static site. With the static files in the project root, the root is deployed as static assets and the Pages Functions, the project's API routes, are silently left undeployed. Stop with an error in that case, explaining that Pages Functions cannot be migrated automatically yet and how to continue for each situation. Projects with their static files in a subdirectory (such as a functions directory for another platform next to public/), projects detected as Pages or with a framework, and interactive runs are unaffected.
🦋 Changeset detectedLatest commit: 189150f The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Codeowners approval required for this PR:
Show detailed file reviewers |
| // is not and continue as a static site, which would deploy the project root | ||
| // as assets and silently drop the Functions (the API routes). Stop instead. | ||
| if ( | ||
| framework.id === staticFramework.id && |
There was a problem hiding this comment.
getFrameworkClassInstance() maps unrecognized detected framework IDs to staticFramework, so this check also fires for projects whose framework was detected but is not in allFrameworksInfos. A root-output project using such a framework and its own functions/ directory now aborts in CI, contrary to the intended "no framework detected" scope. Base this on the detector result instead.
| framework.id === staticFramework.id && | |
| detectedFramework.framework.id === staticFramework.id && |
|
I'm Bonk, and I've done a quick review of your PR. Autoconfig now stops non-interactive root static deployments containing a
|
|
✅ Approved — A narrowly scoped, well-tested guard that stops non-interactive autoconfig from deploying the project root while leaving Pages Functions undeployed. No issues found. The decision is advisory: this comment never approves, blocks or requests changes on the pull request. ✅ All checks passed🔒 Security: ✅ LGTMNo security concerns. The suggested Pages remedy deploys a subdirectory rather than the project root, so files such as 📖 AGENTS.md: ✅ LGTMThe change follows the repository conventions. A changeset is included. 📋 Code Quality: ✅ LGTMThe new guard in ⚡ Performance: ✅ LGTMThe guard adds at most one 📝 Documentation: ✅ LGTMThe changeset and the error message describe the behavior accurately. Reviewed commit: |
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/codemods
@cloudflare/config
@cloudflare/containers-shared
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/runtime-types
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-plugin
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
jamesopstad
left a comment
There was a problem hiding this comment.
The Bonk suggestion seems valid. Otherwise looks good.
workers-devprod
left a comment
There was a problem hiding this comment.
Codeowners reviews satisfied
When a project without a detected framework has a
functionsdirectory, autoconfig asks whether it is a Cloudflare Pages project (isPagesProjectinframework-detection.ts). In non-interactive runs (CI, Workers Builds, coding agents) the prompt falls back to "no", and the project is configured as a static site. When the static files are in the project root,findAssetsDirreturns".", so the project root is deployed as static assets and the Pages Functions (the project's API routes) are not deployed. The deploy succeeds and the routes return the static fallback instead. Interactively, answering "yes" fails with "Automatically migrating from a Pages project to Workers is not yet supported", so only non-interactive runs reach this outcome.Change
In
getDetailsForAutoConfig, stop with anAutoConfigDetectionErrorwhen all of these hold:context.isNonInteractiveOrCI()is true, the same signal that makes the Pages prompt fall back to "no";<projectRoot>/functionsis a directory.The error tells the user how to continue, depending on what
functionsis:(The last line names
cloudflare.config.tsfor thecftarget.) The Pages remedy deploys a subdirectory rather than., because a direct Pages upload of the project root would also upload files such as.env.Scope
The condition is deliberately narrow. These cases are unaffected:
functionsdirectory for another platform (Firebase) next topublic/: autoconfig continues to deploypublic/as before;pages_build_output_diror the Pages cache, and projects with a detected framework;The only callers that reach this are
wrangler deploy(including--dry-run) andwrangler setup.wrangler dev, the Vite plugin and C3 do not, and Pages-to-Workers delegation already declines projects withfunctions/. A static site with a rootindex.htmland a non-Pagesfunctions/folder of its own (for example HTML pages) will now stop in CI and needs one of the listed remedies.Tests cover the error (and its wording for both targets), and the cases that must not throw: static files in a subdirectory, an interactive "no", a detected framework,
functionsas a file, and projects detected as Pages throughpages_build_output_diror the Pages cache. Removing either the static-framework or the directory condition makes a test fail. Checked manually with the built Wrangler, run non-interactively as an agent:wrangler deploy --dry-runandwrangler setup --yeson a project with a rootindex.htmlandfunctions/api/hello.jsstop with the error and write no files, and the same with the HTML underpublic/continues withOutput Directory: public. Fullwranglerand@cloudflare/autoconfigsuites,check:type,type:tests,check:lintandcheck:formatpass locally.