Skip to content

docs(vercel-csr): name the precondition behind zero-config Fastify - #17

Open
DeyangChan wants to merge 1 commit into
mainfrom
docs/vercel-entrypoint-precondition
Open

docs(vercel-csr): name the precondition behind zero-config Fastify#17
DeyangChan wants to merge 1 commit into
mainfrom
docs/vercel-entrypoint-precondition

Conversation

@DeyangChan

Copy link
Copy Markdown
Contributor

What

The vercel-csr backend appendix asserts that Vercel deploys Fastify with no configuration, and tells the reader not to export a handler or add an apps/backend/vercel.json. That is true — but only while Vercel's Git integration builds the project, which is the deployment model infra.md mandates. Detection runs on the push.

The section reads as unconditional, so it applies itself to projects that have left that model.

Why

Observed in a project that had disabled Git deployments (git.deploymentEnabled.main = false) so its release could migrate Neon before the new code went live — something the Git integration cannot sequence. Deploys there run vercel pullvercel build --prebuilt in CI, which builds from fetched project settings and performs no framework detection.

Following this section, the backend's builds entry was removed and server.js was rewritten to app.listen(...). The production deploy failed:

Error: No Output Directory named "public" found after the Build completed.

The backend had been built as a static site. Nothing was promoted, so production stayed on the previous build — but the release was blocked until both halves were reverted together.

The change

Adds two paragraphs to the Entrypoint section:

  • the precondition, and what to check before applying the section
  • the escape hatch for a project that genuinely cannot use Git integration, and the trap inside it: restoring the vercel.json without restoring the handler export deploys a file exporting no handler, which 404s every request. That is worse than the failed build, because it reaches production before a health check catches it.

No rule is reversed. Git integration stays the recommended model, and the guidance to restore it comes before the escape hatch.

Not changed

infra.md, the pack README and deploy.yml.example already say the right thing — Git integration is the only normal path, and the example's header tells you to check the adopted pack's conflict register before copying it. The Entrypoint section was the one place that stated its conclusion without its condition.

🤖 Generated with Claude Code

The Entrypoint section asserted that Vercel deploys Fastify with no
configuration and told the reader not to export a handler or add a
vercel.json. That holds only while Vercel's Git integration builds the
project, which is the model infra.md mandates — detection runs on the push.

A project that has left that model gets no detection: `vercel build
--prebuilt` in CI builds from settings fetched by `vercel pull`, so the
backend builds as a static site and the deploy stops at `No Output Directory
named "public" found`. Observed in a project that had disabled Git
deployments so its release could migrate the database before shipping code.

Records the precondition, the escape hatch, and the trap in the escape hatch:
restoring the vercel.json without restoring the handler export deploys a file
that 404s every request, which reaches production instead of failing the
build.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant