feat(vercel-deployments)!: resolve the deployment target per request

[jhb-dev]

What

BREAKING: the Vercel project and the website URL move into a single required deploymentTarget option, which also accepts a function resolved against the current request. A multi-tenant admin panel can therefore report and deploy the Vercel project of the tenant currently selected.

// before
vercel: { apiToken, projectId: 'prj_abc', teamId }
widget: { websiteUrl: 'https://example.com' }

// after
deploymentTarget: { projectId: 'prj_abc', websiteUrl: 'https://example.com' }
vercel: { apiToken, teamId }

// or, per request
deploymentTarget: async ({ req }) => ({ projectId, websiteUrl })

Migration is mechanical: move vercel.projectId and widget.websiteUrl into deploymentTarget. The option is required, so a config without a target no longer compiles.

One option instead of three keeps the config honest — vercel holds credentials and scope, deploymentTarget says what to deploy, widget stays presentational. websiteUrl is data about the target, not a widget setting.

Behaviour when nothing resolves

A projectId of undefined means the request has no deployment target:

• the widget renders without deployment rows and hides the deploy button
• GET deployments and POST trigger-deployment answer 400 instead of querying Vercel for a missing project

A tenant that has not been deployed yet therefore needs no special casing.

Robustness and cost

• A resolver that throws (e.g. a cookie pointing at a deleted tenant) is caught: the endpoints answer 500 with the message, and the widget renders the error row instead of taking the dashboard down.
• The resolver is called once per request and serves both values, so a multi-tenant setup pays a single document lookup.
• GET ?id=<deploymentId> resolves no target at all — it addresses a deployment directly. This is the path the poller hits every 5s during a build.
• The widget does not await the target before rendering: the card shell and its skeleton appear immediately, and the website link, deploy button and deployment rows each stream in behind their own Suspense boundary.

Tests

• src/utilities/resolveTarget.test.ts — static targets, per-request resolution from a single lookup, and the no-project case
• src/endpoints/endpoints.test.ts — the resolved project reaches the Vercel request, the unresolved-target 400s, the ?id= path skipping resolution, and a throwing resolver answering 500

Dev app demonstration

dev/ gains a tenants collection (with vercelProjectId / websiteUrl) plus posts, and wires @payloadcms/plugin-multi-tenant into dev/src/payload.config.ts. Two tenants are seeded: Acme (deployed) and Not deployed yet. Switching the tenant in the admin panel switches the deployments the widget shows; the deploy button disappears for the undeployed one. The resolver uses select + depth: 0 and disableErrors: true, which is also the pattern the README documents.