Validate Workers deploy config by rissrice2105-agent · Pull Request #647 · profullstack/sh1pt

rissrice2105-agent · 2026-06-05T23:15:48Z

Fixes #646.

Changes:

require worker name and accountId as URL-safe segments
validate env, entrypoint, configPath, routes, and compatibilityDate
validate worker vars as environment variable names with string values
normalize config before plan rendering and Wrangler deploy args
add regression tests for invalid config before CLI work

Validation:

vitest run packages/targets/deploy-workers/src/index.test.ts
tsc -p packages/targets/deploy-workers/tsconfig.json --noEmit

greptile-apps · 2026-06-05T23:18:45Z

Greptile Summary

This PR adds input validation for the Cloudflare Workers deploy config, ensuring name, accountId, routes, compatibilityDate, and vars are validated and normalized before any plan rendering or CLI work occurs. Validation is centralised in a new normalizedConfig helper with regression tests covering all five new rejection paths.

New validators: requireText, requireSegment, optionalText, compatibilityDate, routes, and workerVars cover the full Config shape, composed in normalizedConfig called at build/ship entry points and inside every helper.
Tests: A single it block exercises all five invalid-config scenarios and confirms execMock is never called.

Confidence Score: 4/5

Safe to merge; validation guards run before any CLI or filesystem work and tests cover every new rejection path.

The validation logic is correct and idempotent. normalizedConfig is invoked in every helper as well as at the public entry points, causing repeated validation on already-valid config — currently harmless but worth cleaning up. The compatibilityDate regex accepts logically impossible dates like 2026-13-45, which would surface as a Wrangler error rather than an early validation failure.

packages/targets/deploy-workers/src/index.ts — the redundant normalizedConfig calls in the helper functions.

Important Files Changed

Filename	Overview
packages/targets/deploy-workers/src/index.ts	Adds `normalizedConfig` with per-field validators; called redundantly in every helper as well as in the public entry points. Validation logic is correct but over-applied.
packages/targets/deploy-workers/src/index.test.ts	Adds a regression test covering the five new validation paths; all assertions look correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["build / ship"] --> B["normalizedConfig"]
    B --> C{"requireSegment: name"}
    C -->|invalid| ERR1["throw: requires name / URL-safe"]
    C -->|valid| D{"requireSegment: accountId"}
    D -->|invalid| ERR2["throw: URL-safe segment"]
    D -->|valid| E{"routes map requireText"}
    E -->|"blank route"| ERR3["throw: requires routes[i]"]
    E -->|valid| F{"optionalText fields"}
    F -->|"blank string"| ERR4["throw: requires field"]
    F -->|valid| G{"compatibilityDate regex"}
    G -->|"bad format"| ERR5["throw: YYYY-MM-DD"]
    G -->|valid| H{"workerVars key regex"}
    H -->|"bad key"| ERR6["throw: valid env var name"]
    H -->|valid| I["normalized Config"]
    I --> J["renderPlan / deployArgs / exec"]

_{Reviews (1): Last reviewed commit: "Validate Workers deploy config" | Re-trigger Greptile}

greptile-apps · 2026-06-05T23:18:49Z

@@ -43,6 +104,7 @@ function deployArgs(ctx: { channel: string; projectDir: string }, config: Config
 }

 function renderPlan(ctx: { channel: string; projectDir: string; version: string }, config: Config): string {
+  config = normalizedConfig(config);


Redundant normalizedConfig calls throughout helpers

normalizedConfig is called in both the top-level entry points (build, ship) and again inside every helper (workerEntry, wranglerConfig, deployEnv, deployArgs, renderPlan). A single build invocation triggers roughly 9 normalizations. While idempotent today, this pattern obscures where validation actually occurs and makes the helpers harder to test in isolation. Consider removing the normalizedConfig call from the helpers and ensuring callers always pass an already-normalized config, or keeping validation only at the public build/ship entry points.

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!

greptile-apps · 2026-06-05T23:18:50Z

+  if (date && !/^\d{4}-\d{2}-\d{2}$/.test(date)) {
+    throw new Error('deploy-workers compatibilityDate must use YYYY-MM-DD');
+  }


^\d{4}-\d{2}-\d{2}$ only validates the format, not calendar validity. A value like '2026-13-45' satisfies the regex but is not a real date, and Wrangler would reject it at deploy time. Adding isNaN(Date.parse(date)) as a secondary guard would catch logically invalid dates early.

Suggested change

if (date && !/^\d{4}-\d{2}-\d{2}$/.test(date)) {

throw new Error('deploy-workers compatibilityDate must use YYYY-MM-DD');

}

if (date && (!/^\d{4}-\d{2}-\d{2}$/.test(date) || isNaN(Date.parse(date)))) {

throw new Error('deploy-workers compatibilityDate must use YYYY-MM-DD');

}

github-actions · 2026-06-06T07:07:40Z