feat: Remove RWSDK_DEPLOY for cross-platform builds and fix Windows E2E tests

.github/workflows/playground-e2e-tests.yml

@@ -97,6 +97,7 @@ jobs:
       matrix: ${{ fromJson(needs.setup-matrix.outputs.matrix) }}
     timeout-minutes: 60
     env:
+      DEBUG: rwsdk:e2e:*
       MAX_RETRIES: ${{ (github.event_name == 'schedule' || github.event_name == 'workflow_call') && '10' || '1' }}
       RWSDK_SETUP_PLAYGROUND_ENV_TIMEOUT: ${{ (github.event_name == 'schedule' || github.event_name == 'workflow_call') && '1800000' || '' }} # 30 mins
       RWSDK_DEPLOYMENT_TIMEOUT: ${{ (github.event_name == 'schedule' || github.event_name == 'workflow_call') && '900000' || '' }} # 15 mins
@@ -145,24 +146,26 @@ jobs:
           cache: "pnpm"
 
       - name: Install dependencies
-        shell: bash
         run: pnpm install
 
       - name: Build SDK
-        shell: bash
         run: |
           cd sdk
           pnpm build
 
+      - name: Setup E2E Cache
+        uses: actions/cache@v4
+        with:
+          path: .tmp/rwsdk-e2e/rwsdk-e2e-cache
+          key: ${{ runner.os }}-${{ matrix.package-manager }}-e2e-deps-${{ hashFiles('playground/**/package.json', 'playground/**/pnpm-lock.yaml', 'playground/**/yarn.lock', 'playground/**/package-lock.json') }}
+          restore-keys: |
+            ${{ runner.os }}-${{ matrix.package-manager }}-e2e-deps-
+
       - name: Run Playground E2E Tests
         id: tests
-        shell: bash
         run: |
           pnpm install
           pnpm test:e2e
-        env:
-          CI: 1
-          PACKAGE_MANAGER: ${{ matrix.package-manager }}
 
       - name: Upload playground artifacts
         uses: actions/upload-artifact@v4

.github/workflows/windows-debug.yml

@@ -6,6 +6,18 @@ on:
       cursorTunnelName:
         description: "Optional Cursor tunnel name (<=20 chars); leave blank for random"
         required: false
+      gitUserName:
+        description: "Git user name (from local config)"
+        required: false
+      gitUserEmail:
+        description: "Git user email (from local config)"
+        required: false
+      cloudflareAccountId:
+        description: "Cloudflare Account ID (from local env)"
+        required: false
+      cloudflareApiToken:
+        description: "Cloudflare API Token (from local env)"
+        required: false
 
 jobs:
   debug-session:
@@ -34,5 +46,47 @@ jobs:
           tar -xvf $CursorArchive -C $CursorDir | Out-Null
           Write-Host "Cursor CLI extracted to $CursorDir"
 
+      - name: Download auto-commit script
+        shell: pwsh
+        run: |
+          $AdScriptPath = "$env:GITHUB_WORKSPACE\.tmp\bin\ad"
+          $AdScriptDir = Split-Path -Parent $AdScriptPath
+          if (-not (Test-Path $AdScriptDir)) {
+            New-Item -ItemType Directory -Path $AdScriptDir -Force | Out-Null
+          }
+
+          # Download from gist
+          $GistUrl = "https://gist.githubusercontent.com/justinvdm/fcd6da9d28057addd263214d90793137/raw/e7404b71a0a27b9538890a95dd7804b18ec10c5d/ad"
+          Invoke-WebRequest -Uri $GistUrl -OutFile $AdScriptPath
+
+          # Make executable (bash will handle this)
+          bash -c "chmod +x '$AdScriptPath'"
+
+          # Add to PATH for PowerShell
+          $env:Path += ";$AdScriptDir"
+          [Environment]::SetEnvironmentVariable("Path", $env:Path, [EnvironmentVariableTarget]::User)
+
+          Write-Host "ad script downloaded to: $AdScriptPath"
+
+      - name: Setup Auto-Run Scripts
+        shell: pwsh
+        run: |
+          $params = @{
+            CursorTunnelName = "${{ inputs.cursorTunnelName }}"
+          }
+          if ("${{ inputs.gitUserName }}" -ne "") {
+            $params.GitUserName = "${{ inputs.gitUserName }}"
+          }
+          if ("${{ inputs.gitUserEmail }}" -ne "") {
+            $params.GitUserEmail = "${{ inputs.gitUserEmail }}"
+          }
+          if ("${{ inputs.cloudflareAccountId }}" -ne "") {
+            $params.CloudflareAccountId = "${{ inputs.cloudflareAccountId }}"
+          }
+          if ("${{ inputs.cloudflareApiToken }}" -ne "") {
+            $params.CloudflareApiToken = "${{ inputs.cloudflareApiToken }}"
+          }
+          pwsh -File "$env:GITHUB_WORKSPACE/scripts/setup-windows-debug-env.ps1" @params
+
       - name: Start Interactive Debug Session
         uses: mxschmitt/action-tmate@v3

.notes/justin/worklogs/20-10-29-windows-ci-fixes.md

@@ -0,0 +1,21 @@
+**Fix:** The solution is to normalize the `cacheFolder` path to use forward slashes, which are universally accepted in YAML files, regardless of the operating system. I will modify the path string before it's written to the file.
+
+### 2. Cross-Platform Environment Variables in `package.json`
+
+**Issue:** The `release` script in the `starter` and all `playground` examples used `RWSDK_DEPLOY=1 wrangler deploy` to signal a production build to the Redwood plugin. This syntax for setting environment variables is not cross-platform and fails on Windows with shells like PowerShell or Command Prompt.
+
+**Investigation:** My first thought was to introduce a dependency like `cross-env` to handle this. However, this would add a new dependency to user projects and felt like a workaround rather than a fundamental solution.
+
+We then explored several alternatives to remove the need for the environment variable altogether:
+-   **Using `process.argv`**: This was quickly dismissed as too brittle, as it depends on how Vite is invoked.
+-   **Using Vite's `configResolved` hook**: This was also incorrect because the `dev:init` script needs to run *before* other plugins are instantiated, and this hook runs too late in the lifecycle.
+-   **Exporting a function from `vite.config.mts`**: This is the idiomatic Vite way to handle command-dependent configuration. It would work but would constitute a significant breaking change for all existing users, forcing them to update their `vite.config.mts` files.
+
+**Solution:** The most elegant and backward-compatible solution came from realizing we could rely on the `NODE_ENV` variable that Vite itself sets very early in its process.
+
+-   Vite sets `NODE_ENV` to `'production'` for builds.
+-   Vite sets `NODE_ENV` to `'development'` for the dev server.
+
+This aligns perfectly with our desired behavior: we want to run `dev:init` in any development context, and skip it in any production context. Using `process.env.NODE_ENV !== 'production'` as our condition is more accurate and robust than our previous `RWSDK_DEPLOY` flag. It correctly handles the default cases and also respects any user overrides of `NODE_ENV`.
+
+This change is backward-compatible. For existing users who have `RWSDK_DEPLOY=1` in their scripts, the variable will simply be ignored by the plugin. However, for Windows users, the build was already broken; they will need to remove the variable from their `release` script to get the fix, which is a reasonable expectation. This will be noted for the pull request description.

.notes/justin/worklogs/2025-10-29-windows-ci-build-error.md

@@ -0,0 +1,37 @@
+# Worklog (2025-10-29): Windows CI Build Failures
+
+## Executive Summary
+
+The primary goal is to diagnose and fix a persistent `Rollup failed to resolve import` error that occurs during `pnpm build` on the Windows CI runner. This error seems to be related to Vite's tsconfig path alias resolution, specifically with the `vite-tsconfig-paths` plugin. The build succeeds when run manually in an interactive CI session within the temporary test directory but fails when executed as part of the automated E2E test suite. This suggests an environmental or contextual discrepancy.
+
+## Investigation: `Rollup failed to resolve import`
+
+The E2E tests for `hello-world` and `database-do` are failing on Windows with the following error:
+
+```
+[vite:resolve] Rollup failed to resolve import "@/app/components/__SmokeTest" from "src/worker.tsx".
+file: D:/a/sdk/sdk/playground/hello-world-test-charmed-wombat-2a220268/src/worker.tsx
+```
+
+The key observations are:
+- The error only occurs on Windows runners in the automated CI environment.
+- Manually running `pnpm build` in the temporary directory (e.g., `hello-world-test-charmed-wombat-2a220268`) created by the CI process succeeds without errors.
+- The error originates from the `vite-tsconfig-paths` plugin, which is responsible for resolving aliases defined in `tsconfig.json`.
+
+This points to a subtle difference in how the plugin operates when invoked from our E2E test harness (`execa`) versus an interactive shell. The most likely culprits are differences in the current working directory, path normalization (e.g., handling of `/` vs `\`), or environment variables.
+
+### Next Steps
+
+To diagnose this, the immediate next step is to add instrumentation to the `vite-tsconfig-paths` plugin within the E2E test environment. By logging the inputs and outputs of its path resolution logic, we can pinpoint why the alias resolution is failing. I will modify the E2E test setup to temporarily patch the plugin's code with `console.log` statements before the build is executed.
+
+## Update: The CI vs. Interactive Shell Discrepancy
+
+A key insight is that the build succeeds when run manually in an interactive CI session (via `windows-debug.yml`) but fails in the automated `playground-e2e-tests.yml` workflow.
+
+Upon reviewing the workflow files, a critical difference was identified:
+- The failing `playground-e2e-tests.yml` workflow was forcing all key steps to run with `shell: bash` on Windows runners.
+- The working interactive `windows-debug.yml` workflow uses the default Windows shell, PowerShell (`pwsh`).
+
+This shell difference was the root cause of the path resolution errors. The `bash` environment on Windows (provided by Git) handles paths differently than native shells, causing issues when Node.js scripts spawned child processes for the build.
+
+The fix was to modify `playground-e2e-tests.yml` to conditionally use `pwsh` on Windows runners, aligning the CI environment with the working interactive environment.