chore: run typescript natively #7025
Conversation
|
🚅 Deployed to the trpc-pr-7025 environment in trpc-sse-and-websockets
|
WalkthroughWidespread migration from TSX to native Node execution, Node engine bumps, many imports updated to explicit Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant NPM as Package scripts
participant Node as Node runtime
participant Codegen as scripts/codegen.ts
participant FS as File System
Note over NPM,Node: Postinstall / postbuild / prepack runs
NPM->>Node: run "node scripts/codegen.ts"
Node->>Codegen: execute ESM script (uses import.meta.dirname)
Codegen->>FS: read routers & templates
Codegen->>FS: write generated router files and indexes
Note right of FS: Generated artifacts updated for consumers
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (21)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Comment |
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
@trpc/client
@trpc/next
@trpc/react-query
@trpc/server
@trpc/tanstack-react-query
@trpc/upgrade
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
examples/next-formdata/src/utils/writeFileToDisk.ts (1)
15-24: Add error handling and ensure proper stream cleanup.The file writing lacks error handling and doesn't await stream completion. If writing fails, the stream may not close properly (resource leak), and errors won't be caught.
Apply this diff to add proper error handling:
- const fd = fs.createWriteStream(path.resolve(`${fileDir}/${file.name}`)); - - const fileStream = Readable.fromWeb( - // @ts-expect-error - unsure why this is not working - file.stream(), - ); - for await (const chunk of fileStream) { - fd.write(chunk); - } - fd.end(); + const fd = fs.createWriteStream(path.resolve(`${fileDir}/${file.name}`)); + + try { + const fileStream = Readable.fromWeb( + // @ts-expect-error - unsure why this is not working + file.stream(), + ); + + await new Promise<void>((resolve, reject) => { + fd.on('error', reject); + fd.on('finish', resolve); + fileStream.pipe(fd); + }); + } catch (error) { + fd.destroy(); + throw error; + }examples/express-minimal/package.json (1)
13-13: Critical: test-dev script still references removed tsx dependency.The
test-devscript usestsxtwice, but tsx was removed from devDependencies. This will cause test failures.Apply this diff:
- "test-dev": "start-server-and-test 'tsx src/server' 3000 'tsx src/client'", + "test-dev": "start-server-and-test 'node src/server.ts' 3000 'node src/client.ts'",examples/next-prisma-websockets-starter/package.json (1)
13-13: Inconsistent migration: tsx still referenced but removed from dependencies.Line 13's
dev:wssscript still invokestsx, but tsx appears to have been removed from the project. This will cause runtime failures when developers run the script.Either:
- Update the script to use
node --experimental-strip-types(or rely on default native TS support in Node 23.6.0+), or- Retain
tsxin devDependencies if the migration is incomplete.Also applies to: 35-35
♻️ Duplicate comments (7)
examples/express-minimal/tsconfig.json (1)
10-12: Verify TypeScript version compatibility (same concern as other tsconfig files).These new compiler options require TypeScript 5.5-5.7+. Please ensure compatibility across all examples in the repository.
examples/express-server/tsconfig.json (1)
10-12: TypeScript version compatibility concern (duplicate).Same verification needed for these compiler options as flagged in other tsconfig files.
examples/vercel-edge-runtime/tsconfig.json (1)
13-15: TypeScript version requirement applies here too.Same as
examples/minimal/tsconfig.json, these compiler options require TypeScript 5.7+. The verification script in the minimal example review will check all examples.examples/fastify-server/tsconfig.json (1)
10-12: TypeScript version requirement applies here too.Same TypeScript 5.7+ requirement for
rewriteRelativeImportExtensions. Already flagged in previous tsconfig reviews.examples/.test/diagnostics-big-router/scripts/codegen.ts (2)
7-7: Path concatenation style (same as next-big-router).Same suggestion as
examples/next-big-router/scripts/codegen.ts- preferpath.join()over string concatenation.
15-18: Path concatenation consistency.Same as line 7 and the next-big-router codegen script - consider
path.join()for consistency.examples/.test/diagnostics-big-router/package.json (1)
7-7: Node.js native TypeScript execution requirement.Same critical issue as
examples/lambda-url/package.json- running.tsfiles withnodedirectly requires Node 22.6.0+ with the--experimental-strip-typesflag. This is especially critical in apostinstallscript.
🧹 Nitpick comments (6)
examples/next-formdata/src/utils/writeFileToDisk.ts (2)
6-6: Usepath.resolve()for consistent path construction.String concatenation for paths is less robust than using Node.js path utilities. This also maintains consistency with line 9.
Apply this diff:
- const rootDir = import.meta.dirname + '/../../../../..'; + const rootDir = path.resolve(import.meta.dirname, '../../../../..');
11-13: Consider removing redundant existence check.
fs.mkdirSync()with{ recursive: true }is idempotent and handles existing directories, making theexistsSync()check unnecessary. Removing it also eliminates a potential TOCTOU race condition.Apply this diff:
- if (!fs.existsSync(fileDir)) { - fs.mkdirSync(fileDir, { recursive: true }); - } + fs.mkdirSync(fileDir, { recursive: true });www/src/components/CompaniesUsing.script.ts (1)
20-20: Consider using path.join for consistency.While string concatenation works here, using
path.join(import.meta.dirname, 'CompaniesUsing.script.output.ts')would be more consistent with line 4's approach.Apply this diff:
- import.meta.dirname + '/CompaniesUsing.script.output.ts', + path.join(import.meta.dirname, 'CompaniesUsing.script.output.ts'),vitest.config.ts (1)
42-44: Usepath.join()for path concatenation consistency.While line 10 correctly uses
path.resolve(), this setupFiles path uses string concatenation. For consistency and cross-platform safety, preferpath.join().Apply this diff:
setupFiles: [ - import.meta.dirname + '/packages/tests/suppressActWarnings.ts', + path.join(import.meta.dirname, 'packages/tests/suppressActWarnings.ts'), ],examples/next-big-router/scripts/codegen.ts (2)
7-7: Preferpath.join()for path construction.String concatenation for file paths works but is less maintainable and doesn't normalize paths. Since
pathis already imported fromnode:path, consider usingpath.join().-const ROUTERS_DIR = import.meta.dirname + '/../src/server/routers'; +import path from 'path'; +const ROUTERS_DIR = path.join(import.meta.dirname, '..', 'src', 'server', 'routers');
15-18: Consider usingpath.join()for consistency.Similar to line 7, prefer
path.join()over string concatenation for better cross-platform compatibility and path normalization.const codegenBase = fs.readFileSync( - import.meta.dirname + '/codegen-base.ts', + path.join(import.meta.dirname, 'codegen-base.ts'), 'utf-8', );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (81)
.nvmrc(1 hunks)examples/.test/diagnostics-big-router/package.json(1 hunks)examples/.test/diagnostics-big-router/scripts/codegen.ts(1 hunks)examples/cloudflare-workers/package.json(1 hunks)examples/cloudflare-workers/src/client.ts(1 hunks)examples/express-minimal/package.json(1 hunks)examples/express-minimal/src/client.ts(1 hunks)examples/express-minimal/src/server.ts(1 hunks)examples/express-minimal/tsconfig.json(1 hunks)examples/express-server/package.json(1 hunks)examples/express-server/src/client.ts(1 hunks)examples/express-server/tsconfig.json(1 hunks)examples/fastify-server/package.json(1 hunks)examples/fastify-server/src/client/index.ts(1 hunks)examples/fastify-server/src/config.ts(1 hunks)examples/fastify-server/src/server/index.ts(1 hunks)examples/fastify-server/src/server/router/index.ts(1 hunks)examples/fastify-server/src/server/router/routers/api.ts(1 hunks)examples/fastify-server/src/server/router/routers/posts.ts(1 hunks)examples/fastify-server/src/server/router/routers/sub.ts(1 hunks)examples/fastify-server/src/server/router/trpc.ts(1 hunks)examples/fastify-server/src/server/server.ts(1 hunks)examples/fastify-server/tsconfig.json(1 hunks)examples/lambda-api-gateway/package.json(1 hunks)examples/lambda-api-gateway/src/client.ts(1 hunks)examples/lambda-api-gateway/src/payloadFormatVersionClient.ts(1 hunks)examples/lambda-api-gateway/src/server.ts(0 hunks)examples/lambda-api-gateway/tsconfig.json(1 hunks)examples/lambda-url/package.json(1 hunks)examples/lambda-url/src/client.ts(1 hunks)examples/lambda-url/src/server.ts(0 hunks)examples/lambda-url/tsconfig.json(1 hunks)examples/lazy-load/package.json(1 hunks)examples/lazy-load/src/client/index.ts(1 hunks)examples/lazy-load/src/server/index.ts(1 hunks)examples/lazy-load/src/server/routers/_app.ts(1 hunks)examples/lazy-load/src/server/routers/slow.ts(1 hunks)examples/lazy-load/src/server/routers/user.ts(1 hunks)examples/lazy-load/tsconfig.json(1 hunks)examples/minimal-content-types/server/package.json(1 hunks)examples/minimal-content-types/server/tsconfig.json(1 hunks)examples/minimal-react/server/package.json(1 hunks)examples/minimal-react/server/tsconfig.json(1 hunks)examples/minimal/package.json(1 hunks)examples/minimal/src/client/index.ts(1 hunks)examples/minimal/src/server/index.ts(1 hunks)examples/minimal/src/server/trpc.ts(1 hunks)examples/minimal/tsconfig.json(1 hunks)examples/next-big-router/package.json(1 hunks)examples/next-big-router/scripts/codegen.ts(1 hunks)examples/next-formdata/src/utils/writeFileToDisk.ts(1 hunks)examples/next-prisma-starter/package.json(1 hunks)examples/next-prisma-websockets-starter/package.json(1 hunks)examples/soa/client/client.ts(1 hunks)examples/soa/client/index.ts(1 hunks)examples/soa/faux-gateway/index.ts(1 hunks)examples/soa/package.json(1 hunks)examples/soa/server-a/index.ts(1 hunks)examples/soa/server-a/router.ts(1 hunks)examples/soa/server-b/index.ts(1 hunks)examples/soa/server-b/router.ts(1 hunks)examples/soa/tsconfig.json(1 hunks)examples/standalone-server/package.json(1 hunks)examples/standalone-server/src/client.ts(1 hunks)examples/standalone-server/tsconfig.json(1 hunks)examples/tanstack-react-start/src/routeTree.gen.ts(1 hunks)examples/vercel-edge-runtime/package.json(1 hunks)examples/vercel-edge-runtime/src/client.ts(1 hunks)examples/vercel-edge-runtime/src/index.ts(1 hunks)examples/vercel-edge-runtime/tsconfig.json(1 hunks)package.json(1 hunks)packages/tests/package.json(0 hunks)packages/tests/server/adapters/standalone.http2.test.ts(1 hunks)vitest.config.ts(2 hunks)www/docusaurus.typedoc.js(0 hunks)www/package.json(1 hunks)www/src/components/CompaniesUsing.script.ts(2 hunks)www/src/components/TwitterWall/script.ts(1 hunks)www/src/components/sponsors/script.pull.ts(3 hunks)www/src/components/sponsors/script.push.ts(2 hunks)www/tsconfig.json(1 hunks)
💤 Files with no reviewable changes (4)
- packages/tests/package.json
- examples/lambda-api-gateway/src/server.ts
- examples/lambda-url/src/server.ts
- www/docusaurus.typedoc.js
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
**/*.{ts,tsx}: Always useimport typefor type-only imports
Separate type imports from value imports
Avoid overzealous object destructuring; prefer direct property access
Object destructuring is acceptable when a variable is used 3+ times
Prefer array destructuring
Avoid sparse array destructuring
Never destructure in function parameter declarations
Avoid destructuring potentially nullish nested properties
Maximum 3 parameters per function; use options objects when more
Type parameter names must match /^(T|$)(A-Z)?[0-9]*$/
Prefix unused variables, parameters, and caught errors with_
Prefer namespace imports for validation libraries and large modules (e.g.,import * as z from 'zod',import * as React from 'react')
Follow import order: test helpers, tRPC test imports, third-party, then relative
Never import from@trpc/*/src; import from the package root instead
Do not useSymbol.disposeorSymbol.asyncDispose; usemakeResource()/makeAsyncResource()
Always useawait usingfor resource cleanup
PrefermakeResource()/makeAsyncResource()over manual disposal logic
Avoid non-null assertions (!)
Use proper type guards and optional chaining instead of non-null assertions
Switch statements must be exhaustive for union types
Rely on TypeScript inference; avoid unnecessary explicit return/output types
Use explicit types at public API boundaries, for complex generic constraints, or when inference is insufficient/ambiguous
Use thesatisfiesoperator to retain inference while enforcing shapes
Useas constfor literal type inference when appropriate
Prefer explicit typing overany
Use type assertions sparingly
Leverage TypeScript strict mode features
Files:
examples/fastify-server/src/server/router/routers/posts.tsexamples/minimal/src/client/index.tsexamples/next-formdata/src/utils/writeFileToDisk.tsexamples/express-minimal/src/client.tswww/src/components/CompaniesUsing.script.tsexamples/lazy-load/src/client/index.tsexamples/lambda-url/src/client.tsexamples/vercel-edge-runtime/src/client.tsexamples/fastify-server/src/server/router/index.tsexamples/fastify-server/src/server/router/routers/api.tsexamples/lazy-load/src/server/index.tsexamples/next-big-router/scripts/codegen.tsexamples/soa/server-b/router.tsexamples/fastify-server/src/server/router/trpc.tsexamples/soa/server-a/index.tsexamples/lambda-api-gateway/src/payloadFormatVersionClient.tsexamples/vercel-edge-runtime/src/index.tsexamples/fastify-server/src/config.tsexamples/fastify-server/src/server/server.tsexamples/soa/server-b/index.tsexamples/express-server/src/client.tswww/src/components/sponsors/script.push.tsexamples/lambda-api-gateway/src/client.tsexamples/lazy-load/src/server/routers/slow.tsexamples/lazy-load/src/server/routers/user.tsexamples/tanstack-react-start/src/routeTree.gen.tswww/src/components/TwitterWall/script.tspackages/tests/server/adapters/standalone.http2.test.tsvitest.config.tsexamples/express-minimal/src/server.tsexamples/soa/server-a/router.tsexamples/soa/client/client.tsexamples/lazy-load/src/server/routers/_app.tsexamples/standalone-server/src/client.tsexamples/fastify-server/src/client/index.tsexamples/minimal/src/server/trpc.tsexamples/cloudflare-workers/src/client.tsexamples/soa/client/index.tsexamples/minimal/src/server/index.tsexamples/fastify-server/src/server/router/routers/sub.tswww/src/components/sponsors/script.pull.tsexamples/fastify-server/src/server/index.tsexamples/soa/faux-gateway/index.ts
**/*.{ts,tsx,md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
Use camelCase for file names (with exceptions like TRPC/RPC/HTTP/JSON acronyms, .config.js, .d.ts, and tests)
Files:
examples/fastify-server/src/server/router/routers/posts.tsexamples/minimal/src/client/index.tsexamples/next-formdata/src/utils/writeFileToDisk.tsexamples/express-minimal/src/client.tswww/src/components/CompaniesUsing.script.tsexamples/lazy-load/src/client/index.tsexamples/lambda-url/src/client.tsexamples/vercel-edge-runtime/src/client.tsexamples/fastify-server/src/server/router/index.tsexamples/fastify-server/src/server/router/routers/api.tsexamples/lazy-load/src/server/index.tsexamples/next-big-router/scripts/codegen.tsexamples/soa/server-b/router.tsexamples/fastify-server/src/server/router/trpc.tsexamples/soa/server-a/index.tsexamples/lambda-api-gateway/src/payloadFormatVersionClient.tsexamples/vercel-edge-runtime/src/index.tsexamples/fastify-server/src/config.tsexamples/fastify-server/src/server/server.tsexamples/soa/server-b/index.tsexamples/express-server/src/client.tswww/src/components/sponsors/script.push.tsexamples/lambda-api-gateway/src/client.tsexamples/lazy-load/src/server/routers/slow.tsexamples/lazy-load/src/server/routers/user.tsexamples/tanstack-react-start/src/routeTree.gen.tswww/src/components/TwitterWall/script.tspackages/tests/server/adapters/standalone.http2.test.tsvitest.config.tsexamples/express-minimal/src/server.tsexamples/soa/server-a/router.tsexamples/soa/client/client.tsexamples/lazy-load/src/server/routers/_app.tsexamples/standalone-server/src/client.tsexamples/fastify-server/src/client/index.tsexamples/minimal/src/server/trpc.tsexamples/cloudflare-workers/src/client.tsexamples/soa/client/index.tsexamples/minimal/src/server/index.tsexamples/fastify-server/src/server/router/routers/sub.tswww/src/components/sponsors/script.pull.tsexamples/fastify-server/src/server/index.tsexamples/soa/faux-gateway/index.ts
**/*.test.ts
📄 CodeRabbit inference engine (.cursor/rules/test-patterns.mdc)
**/*.test.ts: ALWAYS useawait using ctx = testServerAndClientResource(...)in tests that need both server and client setup
NEVER use the deprecatedrouterToServerAndClientNew()in tests
ImporttestServerAndClientResourcefrom@trpc/client/__tests__/testClientResource
Create fresh mock instances per test using a factory (e.g.,getMockFetch())
Do not use global mocks that persist across tests
Configure mocks via theclientcallback intestServerAndClientResourceoptions
Usectx.clientfrom the test resource for making tRPC calls
Access server URLs viactx.httpUrlandctx.wssUrl
Configure server options via theserverproperty intestServerAndClientResourceoptions
Configure client options via theclientcallback intestServerAndClientResourceoptions
Use descriptive test names that explain the behavior under test
Focus test names on what the test validates, not just what it does
Use proper TypeScript typing for mocks
Clear mocks between tests when needed
Use factory functions for mock creation to ensure isolation
Files:
packages/tests/server/adapters/standalone.http2.test.ts
{**/*.test.{ts,tsx},**/__tests__/**/*.{ts,tsx}}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
{**/*.test.{ts,tsx},**/__tests__/**/*.{ts,tsx}}: Do not use Testing LibrarywaitFor; usevi.waitForinstead
Tests may use non-null assertions
Tests may have unused variables
Tests may allow floating promises
Files:
packages/tests/server/adapters/standalone.http2.test.ts
packages/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
No
console.login packages; use proper logging instead
Files:
packages/tests/server/adapters/standalone.http2.test.ts
🧬 Code graph analysis (3)
www/src/components/CompaniesUsing.script.ts (1)
www/docusaurus.typedoc.js (1)
path(4-4)
examples/lazy-load/src/server/routers/_app.ts (3)
examples/fastify-server/src/server/router/trpc.ts (1)
router(12-12)examples/lazy-load/src/server/trpc.ts (1)
router(13-13)packages/server/src/unstable-core-do-not-import/router.ts (1)
lazy(105-135)
www/src/components/sponsors/script.pull.ts (1)
www/docusaurus.typedoc.js (1)
fs(3-3)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: test
- GitHub Check: typecheck
- GitHub Check: Lint and auto-fix
🔇 Additional comments (65)
packages/tests/server/adapters/standalone.http2.test.ts (1)
24-24: Code change verified and approved.The project's minimum Node.js version of ^22.18.0 fully supports
import.meta.dirname(available since v20.11.0). The change from__dirnametoimport.meta.dirnameis correct, safe, and properly aligned with ES module modernization.examples/fastify-server/src/server/router/trpc.ts (1)
3-3: LGTM! Explicit .ts extension added correctly.The type-only import correctly uses
import typeand includes the explicit.tsextension as required for NodeNext module resolution.examples/fastify-server/src/config.ts (1)
1-1: LGTM! Type import with explicit extension.The import correctly uses
import typefor the type-only import and includes the explicit.tsextension.examples/fastify-server/src/server/router/routers/posts.ts (1)
3-3: LGTM! Value import with explicit extension.The explicit
.tsextension is correctly added to the value import path.examples/fastify-server/src/server/index.ts (1)
1-6: LGTM! Imports and server startup updated correctly.
- Explicit
.tsextensions added to both imports- The
voidoperator on line 6 appropriately discards the Promise, making the fire-and-forget intent clearexamples/fastify-server/src/server/router/index.ts (1)
1-4: LGTM! All imports consistently updated with explicit extensions.All four import statements correctly include the explicit
.tsextension, maintaining consistency across the router module.examples/fastify-server/src/server/router/routers/sub.ts (1)
2-2: LGTM! Explicit extension added to value import.The import path correctly includes the
.tsextension.examples/fastify-server/src/server/server.ts (1)
4-5: LGTM! Router imports updated with explicit extensions.Both import statements correctly include explicit
.tsextensions for the router context and index modules.examples/fastify-server/src/client/index.ts (1)
9-11: LGTM! All imports correctly updated with explicit extensions.
- Line 9: Value import with
.tsextension- Line 10: Type import correctly uses
import typewith explicit.tsextension- Line 11: Side-effect import with
.tsextensionAll changes follow the coding guidelines and support NodeNext module resolution.
examples/fastify-server/src/server/router/routers/api.ts (1)
2-2: LGTM! Explicit file extension is correct for NodeNext module resolution.The addition of the
.tsextension to the import path is required for NodeNext/Node16 module resolution and aligns with the PR's modernization objectives.examples/tanstack-react-start/src/routeTree.gen.ts (1)
1-86: Generated route tree wiring and typings look soundThe generated file cleanly wires the two routes into the root route, exposes the expected
FileRouteTypes/RootRouteChildrenmappings, and augments both@tanstack/react-routerand@tanstack/react-startwith consistent ids/paths and therouter: Awaited<ReturnType<typeof getRouter>>type. Given that it’s auto-generated and lint/TS checks are intentionally disabled, there’s nothing here that needs manual adjustment.examples/next-big-router/package.json (1)
9-9: LGTM! Migration to native Node.js execution.The postinstall script correctly migrates from tsx to Node with an explicit
.tsextension, and tsx was removed from dependencies.examples/vercel-edge-runtime/package.json (1)
8-8: LGTM! Consistent migration to Node-based execution.The test-dev script correctly migrates from tsx to Node with an explicit
.tsextension, and tsx was removed from devDependencies.examples/express-server/src/client.ts (1)
3-3: LGTM! Explicit .ts extension for NodeNext module resolution.The type-only import correctly adds the
.tsextension, which is required for NodeNext module resolution. This follows the coding guidelines for type-only imports.examples/lambda-api-gateway/src/payloadFormatVersionClient.ts (1)
2-2: LGTM! Explicit .ts extension for type import.The type-only import correctly adds the
.tsextension for NodeNext module resolution, consistent with the broader PR migration.examples/cloudflare-workers/src/client.ts (1)
2-2: LGTM! Explicit .ts extension for type import.The type-only import correctly adds the
.tsextension, aligning with the repository-wide migration to NodeNext module resolution.examples/lambda-api-gateway/package.json (1)
11-12: LGTM! Complete migration to Node-based execution.Both client scripts correctly migrate from tsx to Node with explicit
.tsextensions, and tsx was removed from dependencies. The migration is consistent and complete.examples/lambda-url/src/client.ts (1)
6-6: LGTM! Explicit .ts extension for type import.The type-only import correctly adds the
.tsextension, consistent with the repository-wide migration to NodeNext module resolution.examples/minimal/src/client/index.ts (1)
13-14: LGTM! Explicit .ts extensions added correctly.The explicit TypeScript extensions align with NodeNext module resolution and the type-only import correctly uses
import typeas per coding guidelines.examples/standalone-server/src/client.ts (1)
9-9: LGTM! Type import extension updated correctly.The explicit .ts extension on the type-only import is consistent with the PR's module resolution changes.
examples/vercel-edge-runtime/src/index.ts (1)
2-2: LGTM! Import extension updated correctly.The explicit .ts extension is consistent with the PR's module resolution changes.
examples/express-minimal/src/server.ts (1)
3-3: LGTM! Import extension updated correctly.The explicit .ts extension aligns with NodeNext module resolution.
examples/soa/faux-gateway/index.ts (1)
1-3: LGTM! All import extensions updated consistently.All three imports correctly use explicit .ts extensions, maintaining consistency with the PR's module resolution changes.
examples/minimal-react/server/package.json (1)
7-7: The review comment is incorrect. The code works as-is.Node.js 22.18.0+ has type stripping enabled by default, meaning the
--experimental-strip-typesflag is not required. The project specifies"node": "^22.18.0"in its rootpackage.json, so the current script"dev": "node --watch index.ts"will execute successfully without the flag. The claim that the script "will fail to run" is factually incorrect for the project's specified Node version.Likely an incorrect or invalid review comment.
www/tsconfig.json (1)
7-7: LGTM!The addition of
allowImportingTsExtensions: trueis correctly paired withnoEmit: true(line 8) and aligns with the PR's goal of enabling native TypeScript execution with explicit.tsextensions in imports.examples/lazy-load/src/client/index.ts (1)
8-8: LGTM!The import path correctly updated to use explicit
.tsextension, and properly usesimport typefor the type-only import as per coding guidelines.examples/minimal/src/server/trpc.ts (1)
2-2: LGTM!The import path correctly updated to use explicit
.tsextension for the value import.examples/minimal/src/server/index.ts (1)
6-7: LGTM!Import paths correctly updated to use explicit
.tsextensions, and import order follows the coding guidelines (third-party imports before relative imports).examples/express-minimal/src/client.ts (1)
2-2: LGTM!The import path correctly updated to use explicit
.tsextension, and properly usesimport typefor the type-only import as per coding guidelines.examples/soa/tsconfig.json (1)
3-11: TypeScript version confirmed compatible with all compiler options.The project specifies TypeScript
^5.9.2inexamples/soa/package.json, which exceeds all minimum version requirements for the compiler options used:
rewriteRelativeImportExtensions(TS 5.7+) ✓erasableSyntaxOnly(TS 5.5+) ✓verbatimModuleSyntax(TS 5.0+) ✓No issues found.
www/src/components/TwitterWall/script.ts (1)
132-132: Let me gather more context about how this script is used:Let me verify the project structure and whether www inherits the root package.json constraint:
Let me check the root package.json to see if this is a workspace setup:
Based on my verification, I can now provide the final assessment:
Root package.json specifies Node.js
^22.18.0, which satisfies the minimum v20.11.0 requirement forimport.meta.dirname.Since Node.js version 20.11.0, import.meta.dirname is available as a proper ES module feature. The root
package.jsonconstraint of^22.18.0ensures the requirement is met.However,
www/package.jsondoes not declare anengines.nodefield. While this file will inherit the root constraint in a workspace setup, it's a best practice to explicitly declare the Node.js requirement for independent clarity. Consider adding:{ "engines": { "node": "^22.18.0" } }to
www/package.jsonto ensure the requirement is explicit and maintained if the package is ever treated independently.The code migration itself is correct and compatible with the project's Node.js version.
examples/express-server/package.json (1)
6-7: Add Node.js version constraint and clarify mixed TypeScript execution approach.The
dev:serverscript usingnode --watch src/server.tsrequires Node.js 22.18.0+ for default TypeScript support (earlier versions needed the--experimental-strip-typesflag). However,package.jsonlacks anengines.nodefield, so developers could inadvertently use incompatible versions.The mixed approach is real:
dev:serveruses native Node whiledev:clientusestsx. Since both watch TypeScript files, consider either:
- Adding
"engines": { "node": ">=22.18.0" }to ensure compatibility- Aligning both scripts to use the same runner if the mixed approach isn't intentional
examples/vercel-edge-runtime/src/client.ts (1)
2-2: LGTM! Explicit TypeScript extension added correctly.The type import now uses an explicit
.tsextension, which aligns with the newrewriteRelativeImportExtensionscompiler option and follows theimport typesyntax correctly per coding guidelines.examples/lambda-api-gateway/src/client.ts (1)
2-2: LGTM! Type import updated with explicit extension.The explicit
.tsextension aligns with the repository-wide modernization and correctly usesimport typeper coding guidelines.examples/soa/client/index.ts (1)
1-1: LGTM! Import path updated correctly.The change from
.jsto.tsextension is consistent with the new TypeScript configuration and the value import (not type-only) is correctly using a regular import statement.examples/soa/client/client.ts (1)
2-2: LGTM! Type import path modernized.The type import now uses the explicit
.tsextension, consistent with the repository-wide changes, and correctly follows theimport typesyntax per coding guidelines.examples/minimal-react/server/tsconfig.json (1)
9-11: No issues found — TypeScript version is compatible with all compiler options.The repository consistently uses TypeScript ^5.9.2 across all packages and examples, which exceeds the minimum version requirements for all three compiler options:
rewriteRelativeImportExtensions(5.7+) ✓erasableSyntaxOnly(5.5+) ✓verbatimModuleSyntax(5.0+) ✓The changes are fully supported by the project's TypeScript version.
examples/cloudflare-workers/package.json (2)
8-8: No issues found — verification confirms tsx was never a dependency of cloudflare-workers.The package.json shows no tsx in devDependencies, and the
test-devscript usesnode src/client.tsdirectly rather than tsx. Other example packages that do use tsx are unaffected by changes to cloudflare-workers, as each maintains its own dependencies.
8-8: The code change is correct and no issues were found.Node.js v22.18.0 has type stripping enabled by default, so the script
node src/client.tswill execute correctly without tsx or additional experimental flags. Since the rootpackage.jsonspecifies Node^22.18.0, this change is compatible and requires no modifications.examples/minimal/tsconfig.json (1)
9-11: No TypeScript version compatibility issues found.The project uses TypeScript ^5.9.2, which exceeds the minimum version requirement for
rewriteRelativeImportExtensions(TypeScript 5.7+). All three compiler options are compatible with the specified version.vitest.config.ts (1)
10-10: Node.js version requirement is satisfied.The project specifies a minimum Node.js version of
^22.18.0inpackage.json, which exceeds theimport.meta.dirnamerequirement of Node.js 20.11.0 or higher. All configuration sources (package.json engines, .nvmrc, and CI workflows) confirm Node.js 22.x compatibility. No issues remain.examples/next-prisma-websockets-starter/package.json (1)
5-5: Verify Node version requirement for native TypeScript support.Starting from version 23, the --experimental-strip-types flag is enabled by default, enabling direct TypeScript execution. However, this package specifies
"node": ">=18.15.0"(line 5), which predates native TypeScript support (available from 22.6.0+).Ensure the
engines.nodeversion requirement is updated to reflect the minimum Node version that supports native TypeScript execution, or ensure a compatible runtime is guaranteed elsewhere.Also applies to: 35-35
examples/lambda-api-gateway/tsconfig.json (1)
5-5: ✓ Solid TypeScript configuration for Node.js native support.The compiler options align well with Node.js native TypeScript support requirements, including "rewriteRelativeImportExtensions": true, "verbatimModuleSyntax": true, and "erasableSyntaxOnly": true. Configuration is clean and follows current best practices.
Also applies to: 8-12
examples/lazy-load/tsconfig.json (1)
9-12: ✓ Proper configuration for Node.js native TypeScript support.The compiler options follow the recommended pattern for Node.js native type stripping, including strict module semantics and extension rewriting. Configuration is sound.
examples/minimal-content-types/server/tsconfig.json (1)
4-4: ✓ Properly configured for Node.js native TypeScript.TypeScript compiler options align with native type stripping requirements. Configuration is appropriate.
Also applies to: 6-10
examples/next-prisma-starter/package.json (1)
27-27: The suggested Node version constraint conflicts with Next.js 15.3.1 and overlooks a critical setup issue.The seed script
node prisma/seed.tsrequires TypeScript execution tooling that isn't configured. Currently it will fail on any Node version without either:
- Adding
ts-nodeortsxto devDependencies and updating the seed command, OR- Using the experimental
--experimental-strip-typesflag (not recommended for production)Additionally, Next.js 15.3.1 requires Node.js >= 18.18.0, so enforcing
>=22.6.0would force users to a higher version than Next.js itself requires. The constraint should instead match or slightly exceed Next.js's minimum (e.g.,>=18.18.0or>=20.0.0), not jump to 22.6.0+.Fix required:
- Add
ts-nodeortsxas a devDependency- Update seed script:
"seed": "tsx prisma/seed.ts"(or use ts-node)- Add
engines.nodeconstraint aligned with Next.js 15.3.1:">=18.18.0"or">=20.0.0"⛔ Skipped due to learnings
Learnt from: juliusmarminge Repo: trpc/trpc PR: 6262 File: examples/minimal-react/client/package.json:16-17 Timestamp: 2025-02-12T16:56:46.960Z Learning: In examples and codemods targeting future versions, dependencies may intentionally use upcoming versions (e.g., React v19) or `next` tags, even if those versions haven't been officially released yet.examples/lambda-url/tsconfig.json (1)
5-12: TS config matches Node-native TS recommendations
module: "NodeNext"together withallowImportingTsExtensions,rewriteRelativeImportExtensions,erasableSyntaxOnly, andverbatimModuleSyntaxis exactly the setup recommended for Node’s built‑in TS type‑stripping and.tsimports, withnoEmitkeeping tsc as typecheck-only. Looks good.examples/standalone-server/tsconfig.json (1)
5-12: NodeNext + TS extension flags are consistent;skipLibCheckacceptable for exampleThis mirrors the recommended Node-native TS pattern and matches how other examples are configured.
skipLibCheck: trueis a reasonable perf trade‑off here.package.json (1)
29-30: Usingnode scripts/version.tsis fine with Node 22.18+, assuming only erasable TS syntaxGiven the
engines.node: "^22.18.0", callingnode scripts/version.tsleverages Node’s built‑in TS type‑stripping and is valid as long asversion.tsonly uses erasable TS syntax (no enums, parameter properties, runtime namespaces, etc.) that would require transformation.examples/standalone-server/package.json (1)
6-7: Dev/test scripts now consistently use Node for TS and built JS
dev:server/dev:clientusingnode --watchon.tssources andtest-dev/test-starttargeting the same.tsand built.jsentrypoints are consistent with Node 22+ native TS support and the esbuild output layout. No issues spotted.Also applies to: 13-14
examples/minimal/package.json (1)
7-8: Minimal example scripts cleanly migrated to Node-run.tsand built.jsThe dev and test scripts consistently use
nodefor both.tssources anddist/*/index.jsoutputs, aligning with the new Node-native TS setup and keeping this example in sync with the others.Also applies to: 10-11
examples/soa/server-b/index.ts (1)
2-2: Router import updated to.tsin line with NodeNext + TS extensionsSwitching the router import to
./router.tskeeps the runtime specifier aligned with the actual TS source and matches the NodeNext +allowImportingTsExtensionspattern used elsewhere. Import order is also compliant.examples/lazy-load/src/server/index.ts (1)
5-5: App router import moved to.tsto match TS-native runtime flowUsing
./routers/_app.tsmatches the new TS extension strategy and keeps this entrypoint consistent with the rest of the lazy-load example and the NodeNext configuration.examples/lazy-load/src/server/routers/slow.ts (1)
1-1: LGTM: Import path updated to explicit TypeScript extension.The migration from
.jsto.tsextension aligns with the PR's objective to run TypeScript natively.examples/soa/server-a/router.ts (1)
1-1: LGTM: Import path updated consistently.The change from
.jsto.tsextension is consistent with the TypeScript native migration.examples/soa/server-b/router.ts (1)
1-1: LGTM: Import path updated consistently.This change mirrors the pattern across other SOA example files and correctly uses the explicit
.tsextension.examples/lazy-load/src/server/routers/user.ts (1)
5-6: LGTM: Import paths updated to TypeScript extensions.The migration from
.jsto.tsextensions is correct and consistent with the PR objective.examples/soa/server-a/index.ts (1)
2-2: LGTM: Import path updated correctly.The change to use the explicit
.tsextension is consistent with the TypeScript native migration strategy.www/src/components/sponsors/script.pull.ts (2)
4-4: LGTM: Type import updated with explicit extension.The use of
import typeis correct for type-only imports, and adding the.tsextension aligns with the migration strategy.
193-193: Verified: Node.js version supportsimport.meta.dirname.The project specifies a minimum Node.js version of 22.18.0 (package.json) and 22.21 (.nvmrc), which exceeds the requirement introduced in v20.11.0. The migration from
__dirnametoimport.meta.dirnameis fully supported.www/src/components/sponsors/script.push.ts (2)
4-4: LGTM: Import path updated correctly.The change to use the explicit
.tsextension is correct for this value import.
146-146: Verify Node.js version compatibility (same as script.pull.ts).As with script.pull.ts, the use of
import.meta.dirnamerequires Node.js 20.11.0+ or 21.2.0+. Ensure this aligns with the project's Node.js version requirements.examples/lazy-load/src/server/routers/_app.ts (2)
2-2: LGTM: Import path updated to TypeScript extension.The change from
.jsto.tsis consistent with the native TypeScript execution approach.
5-7: LGTM: Dynamic import paths updated correctly.The lazy-loaded module paths now use
.tsextensions, which is correct for the new TypeScript module resolution configuration. Thelazy()helper from tRPC will properly handle these dynamic imports.www/package.json (1)
15-16: Node.js cannot execute TypeScript files without a loader or transpiler—scripts will fail at runtime.The four npm scripts (lines 15–16, 19, 21) attempt to run
.tsfiles directly with thenodecommand, but no TypeScript execution mechanism is configured:
- No Node.js loader (
--loader) in package.json or .npmrc- No
--experimental-strip-typesflag configured- No build step that pre-compiles scripts
- No tsx or ts-node in devDependencies (tsx was removed)
- tsconfig.json has
noEmit: true(doesn't generate JavaScript output)The script files contain TypeScript syntax and ES6 imports that require runtime transpilation. Without a loader or compilation step, these will fail with syntax/module errors when invoked.
Required fixes:
- Configure a Node.js loader (e.g., tsx, esbuild-register, or use
--experimental-strip-typesflag if Node v22+)- OR add a build step that pre-compiles scripts to JavaScript before execution
- Update npm scripts with appropriate flags or add tsx back as devDependency with loader configuration
⛔ Skipped due to learnings
Learnt from: CR Repo: trpc/trpc PR: 0 File: .cursor/rules/coding-guidelines.mdc:0-0 Timestamp: 2025-09-05T16:48:06.982Z Learning: Applies to **/*.{ts,tsx} : Leverage TypeScript strict mode featuresLearnt from: CR Repo: trpc/trpc PR: 0 File: .cursor/rules/coding-guidelines.mdc:0-0 Timestamp: 2025-09-05T16:48:06.982Z Learning: Applies to packages/**/*.{ts,tsx} : No `console.log` in packages; use proper logging insteadLearnt from: CR Repo: trpc/trpc PR: 0 File: .cursor/rules/upgrade-tests.mdc:0-0 Timestamp: 2025-09-05T15:17:32.520Z Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : Do NOT import legacy-only helpers like createAppRouter from './__testHelpers' in upgrade-package testsLearnt from: CR Repo: trpc/trpc PR: 0 File: .cursor/rules/upgrade-tests.mdc:0-0 Timestamp: 2025-09-05T15:17:32.520Z Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : For migration testing, exercise both legacy and modern patterns via ctx.rq and ctx.trq within the same test when relevantLearnt from: juliusmarminge Repo: trpc/trpc PR: 6789 File: packages/tanstack-react-query/tsdown.config.ts:1-24 Timestamp: 2025-06-09T14:01:20.033Z Learning: In the tRPC monorepo, packages/tests and packages/upgrade don't need main/module/types fields in their package.json because tests is not distributed and upgrade just exposes a binary.
| import path from 'path'; | ||
|
|
||
| const WWW_ROOT = path.join(__dirname, '../../'); | ||
| const WWW_ROOT = path.join(import.meta.dirname, '../../'); |
There was a problem hiding this comment.
🧩 Analysis chain
Verify ES module configuration for import.meta.dirname.
The usage of import.meta.dirname is correct for ES modules. Ensure that this package has "type": "module" in its package.json or this script is run with proper ES module support.
Run the following script to verify the module type configuration:
🏁 Script executed:
#!/bin/bash
# Check if www/package.json has "type": "module"
fd -t f "package.json" www --max-depth 2 --exec cat {} \; | jq -r 'select(.type == "module") | "Module type: \(.type)"'
# Also check for tsconfig module settings
fd -t f "tsconfig.json" www --max-depth 2 --exec cat {} \; | jq -r '.compilerOptions.module // empty'Length of output: 6
I need to get more complete information about the package.json configuration. Let me run a more direct verification:
---
🏁 Script executed:
```shell
#!/bin/bash
# Direct check for www/package.json
echo "=== www/package.json ==="
cat www/package.json 2>/dev/null | jq '.type' || echo "Not found or no type field"
# Full tsconfig check
echo "=== www/tsconfig.json compilerOptions.module and target ==="
cat www/tsconfig.json 2>/dev/null | jq '.compilerOptions | {module, target}' || echo "Not found"
Length of output: 284
Let me run a corrected verification script:
🏁 Script executed:
#!/bin/bash
# Check www/package.json exists and show type field
echo "=== www/package.json type field ==="
if [ -f www/package.json ]; then
jq '.type' www/package.json 2>/dev/null || echo "(no type field found)"
else
echo "www/package.json not found"
fi
# Show full compilerOptions from tsconfig
echo "=== www/tsconfig.json compilerOptions.module ==="
if [ -f www/tsconfig.json ]; then
jq '.compilerOptions.module' www/tsconfig.json 2>/dev/null || echo "Not found"
else
echo "www/tsconfig.json not found"
fi
# Show target
echo "=== www/tsconfig.json compilerOptions.target ==="
if [ -f www/tsconfig.json ]; then
jq '.compilerOptions.target' www/tsconfig.json 2>/dev/null || echo "Not found"
else
echo "File not found"
fiLength of output: 148
Let me inspect the actual file contents to understand the full configuration:
🏁 Script executed:
#!/bin/bash
# Show full www/package.json
echo "=== www/package.json (full) ==="
cat www/package.json
echo -e "\n=== www/tsconfig.json (full) ==="
cat www/tsconfig.json
echo -e "\n=== Root package.json type field ==="
if [ -f package.json ]; then
jq '.type' package.json 2>/dev/null || echo "(no type field found)"
else
echo "Root package.json not found"
fiLength of output: 4198
Add "type": "module" to www/package.json.
The verification confirms a critical issue: www/package.json does not have "type": "module", while import.meta.dirname requires ES module support. When the script runs via node ./src/components/CompaniesUsing.script.ts, Node.js resolves the closest package.json (www/package.json), treating the file as CommonJS without the "type": "module" field. This will cause import.meta.dirname to fail at runtime.
Add "type": "module" to www/package.json.
🤖 Prompt for AI Agents
In www/src/components/CompaniesUsing.script.ts around line 4, Node will treat
files as CommonJS because www/package.json lacks "type": "module", causing
import.meta.dirname to fail at runtime; fix by adding "type": "module" at the
top-level of www/package.json (i.e., "type": "module") so Node treats the
package as ESM, then reinstall/restart any processes or re-run the script to
confirm import.meta.dirname resolves correctly.
juliusmarminge
force-pushed
the
node-native-ts
branch
from
c07cc86 to
fd65803
Compare
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
.github/setup/action.yml(1 hunks).tool-versions(1 hunks)examples/cloudflare-workers/package.json(1 hunks)examples/express-minimal/package.json(1 hunks)examples/express-server/package.json(1 hunks)examples/fastify-server/package.json(1 hunks)examples/lambda-api-gateway/package.json(1 hunks)examples/lambda-url/package.json(1 hunks)examples/lazy-load/package.json(1 hunks)examples/minimal-content-types/server/package.json(1 hunks)examples/minimal-react/server/package.json(1 hunks)examples/minimal/package.json(1 hunks)examples/standalone-server/package.json(1 hunks)examples/vercel-edge-runtime/package.json(1 hunks)package.json(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (10)
- examples/lambda-url/package.json
- examples/express-minimal/package.json
- examples/standalone-server/package.json
- package.json
- examples/lazy-load/package.json
- examples/express-server/package.json
- examples/lambda-api-gateway/package.json
- examples/minimal/package.json
- examples/cloudflare-workers/package.json
- examples/fastify-server/package.json
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/upgrade-tests.mdc:0-0
Timestamp: 2025-09-05T15:17:32.520Z
Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : For migration testing, exercise both legacy and modern patterns via ctx.rq and ctx.trq within the same test when relevant
Learnt from: barelyhuman
Repo: trpc/trpc PR: 6530
File: packages/upgrade/src/bin/cli.ts:218-222
Timestamp: 2025-02-19T20:31:52.088Z
Learning: The CLI options `trpcFile` and `trpcImportName` in `packages/upgrade/src/bin/cli.ts` are temporary and planned to be removed in favor of using automatically discovered references from the TypeScript program.
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/upgrade-tests.mdc:0-0
Timestamp: 2025-09-05T15:17:32.520Z
Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : Import both 'trpc/react-query' as rq (legacy) and 'trpc/tanstack-react-query' as trq (modern) when writing migration tests
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Never import from `trpc/*/src`; import from the package root instead
Learnt from: juliusmarminge
Repo: trpc/trpc PR: 6789
File: packages/tanstack-react-query/tsdown.config.ts:1-24
Timestamp: 2025-06-09T14:01:20.033Z
Learning: In the tRPC monorepo, packages/tests and packages/upgrade don't need main/module/types fields in their package.json because tests is not distributed and upgrade just exposes a binary.
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Follow import order: test helpers, tRPC test imports, third-party, then relative
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/upgrade-tests.mdc:0-0
Timestamp: 2025-09-05T15:17:32.520Z
Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : Do NOT import legacy-only helpers like createAppRouter from './__testHelpers' in upgrade-package tests
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Leverage TypeScript strict mode features
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.tsx : Use the JSX runtime (no need to import React for JSX)
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx,md,mdx} : Use camelCase for file names (with exceptions like TRPC/RPC/HTTP/JSON acronyms, .config.js, .d.ts, and tests)
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Separate type imports from value imports
📚 Learning: 2025-06-09T14:01:20.033Z
Learnt from: juliusmarminge
Repo: trpc/trpc PR: 6789
File: packages/tanstack-react-query/tsdown.config.ts:1-24
Timestamp: 2025-06-09T14:01:20.033Z
Learning: In the tRPC monorepo, packages/tests and packages/upgrade don't need main/module/types fields in their package.json because tests is not distributed and upgrade just exposes a binary.
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.jsonexamples/vercel-edge-runtime/package.json
📚 Learning: 2025-09-05T15:16:31.379Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/tanstack-react-query-tests.mdc:0-0
Timestamp: 2025-09-05T15:16:31.379Z
Learning: Applies to packages/tanstack-react-query/**/*.test.tsx : Import React testing utilities with `import * as React from 'react';`
Applied to files:
examples/minimal-react/server/package.json
📚 Learning: 2025-09-05T16:48:06.982Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Leverage TypeScript strict mode features
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.jsonexamples/vercel-edge-runtime/package.json
📚 Learning: 2025-09-05T16:48:06.982Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Use proper type guards and optional chaining instead of non-null assertions
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.json
📚 Learning: 2025-09-05T16:48:06.982Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Follow import order: test helpers, tRPC test imports, third-party, then relative
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.json
📚 Learning: 2025-09-05T16:48:06.982Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Prefer array destructuring
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.json
📚 Learning: 2025-09-05T15:16:31.379Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/tanstack-react-query-tests.mdc:0-0
Timestamp: 2025-09-05T15:16:31.379Z
Learning: Applies to packages/tanstack-react-query/**/*.test.tsx : Import React Query types from `tanstack/react-query` as needed
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.json
📚 Learning: 2025-09-05T16:48:06.982Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-09-05T16:48:06.982Z
Learning: Applies to **/*.{ts,tsx} : Use `as const` for literal type inference when appropriate
Applied to files:
examples/minimal-react/server/package.jsonexamples/minimal-content-types/server/package.json
📚 Learning: 2025-09-05T15:17:32.520Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/upgrade-tests.mdc:0-0
Timestamp: 2025-09-05T15:17:32.520Z
Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : Do NOT import legacy-only helpers like createAppRouter from './__testHelpers' in upgrade-package tests
Applied to files:
examples/vercel-edge-runtime/package.json
📚 Learning: 2025-09-05T15:17:32.520Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/upgrade-tests.mdc:0-0
Timestamp: 2025-09-05T15:17:32.520Z
Learning: Applies to packages/upgrade/**/*.{test,spec,trpc,snap}.tsx : For migration testing, exercise both legacy and modern patterns via ctx.rq and ctx.trq within the same test when relevant
Applied to files:
examples/vercel-edge-runtime/package.json
📚 Learning: 2025-09-05T15:16:48.745Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-09-05T15:16:48.745Z
Learning: Applies to **/*.test.ts : Configure server options via the `server` property in `testServerAndClientResource` options
Applied to files:
examples/vercel-edge-runtime/package.json
📚 Learning: 2025-09-05T16:48:19.113Z
Learnt from: CR
Repo: trpc/trpc PR: 0
File: .cursor/rules/pnpm.mdc:0-0
Timestamp: 2025-09-05T16:48:19.113Z
Learning: Applies to {pnpm-lock.yaml,yarn.lock,package-lock.json,bun.lockb} : Use pnpm as the package manager; prefer pnpm-lock.yaml and avoid yarn.lock, package-lock.json, or bun.lockb at the repository root
Applied to files:
.github/setup/action.yml.tool-versions
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
- GitHub Check: E2E-tests (soa)
- GitHub Check: E2E-tests (vercel-edge-runtime)
- GitHub Check: E2E-tests (next-prisma-todomvc)
- GitHub Check: E2E-tests (next-prisma-starter)
- GitHub Check: E2E-tests (next-minimal-starter)
- GitHub Check: E2E-tests (cloudflare-workers)
- GitHub Check: E2E-tests (.experimental/next-app-dir)
- GitHub Check: E2E-tests (.test/diagnostics-big-router)
- GitHub Check: E2E-tests (minimal-react)
- GitHub Check: E2E-tests (.test/internal-types-export)
- GitHub Check: E2E-tests (express-minimal)
- GitHub Check: E2E-tests (.test/ssg)
- GitHub Check: E2E-tests (express-server)
- GitHub Check: Test a monorepo using built declaration files
- GitHub Check: Release using pkg.pr.new
- GitHub Check: E2E-tests (Bun) (bun, ubuntu-latest)
- GitHub Check: E2E-tests (Deno) (deno-deploy)
- GitHub Check: typecheck-www
- GitHub Check: test
- GitHub Check: Lint and auto-fix
🔇 Additional comments (5)
examples/minimal-react/server/package.json (1)
4-12: Well-executed native TypeScript modernization.The changes correctly align with the shift to native Node.js TypeScript execution:
"type": "module"enables ES modules (required for native TS transpilation)."engines": { "node": "^22.20.0" }ensures the minimum Node version supports--watchwith.tsfiles."dev"script properly replacestsx watchwithnode --watchfor native support.- Removal of
tsxfrom devDependencies is appropriate.examples/minimal-content-types/server/package.json (1)
4-12: Consistent modernization pattern maintained.Identical to
examples/minimal-react/server/package.json, this file correctly implements native TypeScript support across the examples directory. The"engines"constraint and module configuration align with the PR's modernization objectives..github/setup/action.yml (1)
9-9: ---Node.js version successfully centralized via package.json.
The change from hard-coded
node-version: 22.xtonode-version-file: package.jsonproperly centralizes version management. The root package.json declaresengines.node: "^22.20.0", which ensures CI uses the same Node version as specified in the project configuration.examples/vercel-edge-runtime/package.json (2)
5-7: Verify the Node version constraint is appropriate.The constraint
^22.20.0requires Node 22+, which is more restrictive than the current LTS (Node 20). Confirm this version requirement is necessary for the TypeScript native execution setup and aligns with your project's support matrix.
11-11: The original review comment is based on incorrect assumptions about Node's capabilities and can be safely ignored.Node 22 (>= v22.18.0, which includes 22.20.0) has native type stripping enabled by default, allowing Node to run .ts files by removing erasable TypeScript type annotations at runtime. The repository's setup is properly configured for this:
- tsconfig.json includes
"erasableSyntaxOnly": true, explicitly designed for Node's native TypeScript execution- All relative imports use explicit
.tsextensions (required for Node native TypeScript)- Type imports/exports use
import typeandexport typekeywords (required for Node native TypeScript)- No non-erasable syntax (enums, namespaces, parameter properties, JSX, etc.) is present in the source files
- devDependencies correctly has tsx removed
The
test-devscript will work as intended withnode src/client.tson Node 22.20.0+.Likely an incorrect or invalid review comment.
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
|
Not sure how to update the node version in Railway |
railway-app
bot
had a problem deploying
to
next-prisma-websockets-starter (trpc-sse-and-websockets / trpc-pr-7025)
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR is being reviewed by Cursor Bugbot
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| "type": "module", | ||
| "engines": { | ||
| "node": "^22.18.0", | ||
| "node": "^22.20.0", |
There was a problem hiding this comment.
Bug: CommonJS files break with ESM module type
Adding "type": "module" to the root package.json causes all .js files in subdirectories without their own package.json to be interpreted as ESM modules. However, several files in the www directory use CommonJS syntax (module.exports, require(), __dirname), including www/docusaurus.typedoc.js, www/docusaurus.twitterReload.js, www/mdxToJsx.js, www/shikiTwoslash.config.js, www/src/utils/env.js, and files in www/og-image/. These files will fail at runtime with syntax errors when Node.js tries to parse them as ESM modules.
little modernization
Summary by CodeRabbit
Chores
New Features
✏️ Tip: You can customize this high-level summary in your review settings.
Note
Modernizes the repo to run TS natively: standardizes on Node 22.x, replaces tsx with node, adopts NodeNext TS config, updates imports/paths, and adds a generated TanStack Router route tree.
22.x(package.jsonengines,.nvmrc,.tool-versions).actions/setup-nodewithnode-version-file: package.json.tsxwith nativenode(watch/exec) across examples, www, and root scripts; removetsxwhere unused.module: NodeNextand enablerewriteRelativeImportExtensions,verbatimModuleSyntax, etc.; allow TS extension imports where needed..tsimports and useimport.meta.dirnameinstead of__dirname/fileURLToPath.routeTree.gen.tsfor the React Start example.vitest.config.tsand tests to useimport.meta.dirnameand NodeNext-compatible paths.Written by Cursor Bugbot for commit 6377c89. This will update automatically on new commits. Configure here.