cloudflare / vinext

* fix: install react-server-dom-webpack during init and deploy for App Router vinext init was missing react-server-dom-webpack from its dependency list, causing 'Could not resolve react-server-dom-webpack/server.edge' errors on fresh create-next-app projects. Additionally, react-server-dom-webpack@19.2.4 requires react@^19.2.4, but create-next-app ships react@19.2.3 -- the version mismatch caused npm to nest rsdw inside vinext/node_modules where Vite can't resolve it. Fix: add react-server-dom-webpack to getInitDeps for App Router, detect when the installed React version is too old, and upgrade react/react-dom as regular dependencies before installing dev deps (avoiding ERESOLVE peer-dep conflicts and keeping react in 'dependencies' rather than 'devDependencies'). Also applies the same fix to vinext deploy for parity, and adds a CI job that scaffolds a real create-next-app project, runs vinext init, and verifies the dev server returns HTTP 200. Closes #22 * refactor: use createRequire for package resolution instead of direct node_modules reads Address review feedback (PR #18 pattern): replace fs.existsSync(node_modules/...) with createRequire-based resolution, which handles hoisting, pnpm symlinks, monorepos, and Yarn PnP correctly. - deploy.ts: extract isPackageResolvable() helper using createRequire, use it in getMissingDeps for react-server-dom-webpack detection - init.ts: refactor getReactUpgradeDeps() to use createRequire + findPackageVersion walk-up pattern instead of reading node_modules/react/package.json directly - tests: add isPackageResolvable unit tests, use dependency injection for getMissingDeps rsdw test (Vitest's createRequire intercepts resolution) * ci: add Windows to create-next-app smoke test Run the create-next-app compatibility test on both ubuntu-latest and windows-latest. Replace bash-specific server health check (curl, kill, backgrounding) with a cross-platform Node script using child_process and http. Use runner.temp instead of /tmp for portable paths. * fix: use pathToFileURL for dynamic import() calls on Windows On Windows, Node's ESM loader requires file:// URLs for absolute paths. Bare paths like D:\... are rejected with ERR_UNSUPPORTED_ESM_URL_SCHEME. Wrap all dynamic import() calls that receive absolute paths from require.resolve() or path.join() with pathToFileURL().href: - index.ts: RSC plugin import, RSC transforms import, PostCSS config loading, PostCSS plugin resolution (5 call sites) - cli.ts: Vite module import from project root * fix: pathToFileURL for cache-runtime codegen and test imports Additional Windows fixes found via PR #43 review: - index.ts: use pathToFileURL for runtimeModulePath in 'use cache' transform code generation (2 locations) — these embed absolute paths into generated import() statements via JSON.stringify - pages-router.test.ts: wrap 9 import(serverEntryPath) calls with pathToFileURL so tests work on Windows