Conversation
Replace the srvx + Hono + vite-plugin-srvx setup with a simpler registry.start() that starts the manager server, serves static files from public/ if it exists, and runs the actor driver. This is now the recommended way to run RivetKit. Key changes: - Add registry.start() method to Registry class - Add publicDir config option for static file serving - Move @hono/node-server and @hono/node-ws to regular deps - Update client default endpoint to http://localhost:6420 - Add deprecation warning when no endpoint is passed to client - Migrate all 30 examples to the new pattern - Update quickstart docs and client docs Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Replace separate actors.ts/server.ts with single index.ts + registry.start() - Update all code examples to import from "./index" instead of "./actors" - Standardize createClient endpoint to localhost:6420 (not 8080) - Remove srvx references, replace with npx tsx --watch - Add registry.start() to runtime-modes comparison and registry-configuration - Update skill-base-rivetkit.md to reference registry.start() as primary - Update StepRunServer default file to index.ts - Update react quickstart to remove StepSetupServer/StepRunServer Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
🚅 Deployed to the rivet-pr-4477 environment in rivet-frontend
|
PR Review: registry.start()This PR significantly simplifies the RivetKit developer experience. The consolidation of examples to a single src/index.ts entry point and the new registry.start() method is a clear DX improvement. Below are my observations. Potential Issues 1. Hardcoded localhost:6420 may break production deployments Every frontend example now uses a hardcoded localhost:6420 endpoint. In production, registry.start() serves the built frontend as static files (via publicDir), but the built JS bundle still references localhost:6420, which will fail for any cloud deployment. The old pattern using location.origin was production-safe because it was relative to the serving origin. Consider using a Vite env variable or document clearly that the hardcoded endpoint is local-dev-only. 2. start() mutates the stored config object in place In registry/index.ts, start() directly sets publicDir and serveManager on the stored config object. Mutating config after construction is unexpected. Calling start() twice would permanently alter the stored config. Consider applying these defaults locally within the method rather than touching the stored config. 3. Module-level hasWarnedMissingEndpoint persists across test runs The warning flag in src/client/config.ts fires at most once per process lifetime. In a test suite creating multiple clients without an endpoint, the warning only appears once, which may make the deprecation harder to notice during development. 4. Relative path for static file serving is cwd-dependent In runtime/index.ts the static serving uses a relative publicDir path. If the server is started from outside the project root, static files will not be found even though existsSync passed. Consider resolving to an absolute path at startup. Minor Observations 5. Suspicious cross-example rename in diff The diff shows examples/trpc/src/actors.ts renamed to examples/hono/src/index.ts. This looks like a git rename detection artifact spanning two unrelated example directories. Worth verifying both trpc and hono examples are in their expected state. 6. Error messages reference setup() for size config keys The updated error messages say to configure via setup() with maxIncomingMessageSize. Confirm this key is accessible via setup() and not only via the now-removed start() config. 7. hono example keeps two files alongside the new convention The hono example still has src/server.ts alongside src/index.ts (intentional for the custom routing use case). A brief README note would help given CLAUDE.md now says single entry point. 8. No tests for registry.start() behavior The driver test suite does not cover the new start() method - specifically the serveManager defaulting, publicDir defaulting, and remote endpoint detection branching. A test for the endpoint detection logic would add confidence. Positive Highlights
|
Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context.
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist: