feat: Astro framework, additionally with oRPC integration #600
Conversation
WalkthroughAdds Astro as a supported frontend across CLI types, prompts, helpers, templates, and tests; includes Astro-specific template scaffolding, ORPC web client templates (TanStack Query + client), dependency resolution, env/CORS handling, and UI tech list updates. Changes are deterministic and scoped to CLI app, templates, and web constants. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User
participant AstroPage as Astro Page
participant ReactComp as React (OrpcApiStatus)
participant TSQ as TanStack Query
participant ORPC as ORPC Client
participant Server as API Server
User->>AstroPage: GET /
AstroPage->>ReactComp: mount client:only="react"
ReactComp->>TSQ: useQuery(orpc.healthCheck.queryOptions())
TSQ->>ORPC: execute healthCheck via RPCLink
ORPC->>Server: RPC request (batched link)
Server-->>ORPC: JSON response
ORPC-->>TSQ: resolve result
TSQ-->>ReactComp: data/loading/error
ReactComp-->>User: render status (Connected/Disconnected/Checking)
note right of ORPC: onError logs RPC errors
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
devzom
force-pushed
the
feature/201-add-astro-framework
branch
from
3dd7273 to
9bf139a
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
apps/cli/templates/frontend/astro/public/robots.txt (1)
1-5: Consider adding a trailing newline.The robots.txt content is correct and permissive (allows all bots). However, the file lacks a trailing newline at the end. While not critical, POSIX standards recommend text files end with a newline character for better compatibility with text processing tools.
apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs (1)
10-11: Consider standardizing error logging format.The QueryCache error handler formats the message (
Error: ${error.message}), while the RPCLink interceptor logs the raw error object. For consistency and better debugging, consider using the same format in both locations.Apply this diff to standardize error logging:
interceptors: [ onError((error) => { - console.error(error) + console.error(`RPC Error: ${error.message}`, error) }) ],Also applies to: 27-29
apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs (1)
1-3: Consider consolidating QueryClientProvider import.The import statements include both named imports from
@tanstack/react-query. While functionally correct, you could consolidate lines 2-3 into a single import for better readability.Apply this diff to consolidate the imports:
import { orpc, queryClient } from '../lib/orpc'; -import { useQuery } from '@tanstack/react-query'; -import { QueryClientProvider } from '@tanstack/react-query'; +import { useQuery, QueryClientProvider } from '@tanstack/react-query';
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
apps/cli/templates/frontend/astro/public/favicon.svgis excluded by!**/*.svg
📒 Files selected for processing (23)
apps/cli/src/helpers/core/api-setup.ts(3 hunks)apps/cli/src/helpers/core/auth-setup.ts(1 hunks)apps/cli/src/helpers/core/create-readme.ts(2 hunks)apps/cli/src/helpers/core/env-setup.ts(3 hunks)apps/cli/src/helpers/core/payments-setup.ts(1 hunks)apps/cli/src/helpers/core/post-installation.ts(1 hunks)apps/cli/src/helpers/core/template-manager.ts(2 hunks)apps/cli/src/prompts/frontend.ts(1 hunks)apps/cli/src/types.ts(1 hunks)apps/cli/src/utils/compatibility-rules.ts(1 hunks)apps/cli/src/utils/compatibility.ts(1 hunks)apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs(1 hunks)apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs(1 hunks)apps/cli/templates/frontend/astro/_gitignore(1 hunks)apps/cli/templates/frontend/astro/astro.config.mjs.hbs(1 hunks)apps/cli/templates/frontend/astro/package.json.hbs(1 hunks)apps/cli/templates/frontend/astro/public/robots.txt(1 hunks)apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs(1 hunks)apps/cli/templates/frontend/astro/src/pages/index.astro.hbs(1 hunks)apps/cli/templates/frontend/astro/src/styles/global.css(1 hunks)apps/cli/templates/frontend/astro/tsconfig.json.hbs(1 hunks)apps/cli/test/frontend.test.ts(2 hunks)apps/web/src/lib/constant.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/convex_rules.mdc)
**/*.{ts,tsx}: Use Id from './_generated/dataModel' to type document ids (e.g., Id<'users'>)
Ensure Record key/value types align with validators (e.g., v.record(v.id('users'), v.string()) => Record<Id<'users'>, string>)
Be strict with types for document ids; prefer Id<'table'> over string
Use 'as const' for string literals in discriminated unions
When using Array and Record types, declare with explicit generic types (e.g., const arr: Array = ...)
**/*.{ts,tsx}: Use TypeScript type aliases instead of interface declarations.
Do not use explicit return types in TypeScript.
Files:
apps/cli/test/frontend.test.tsapps/web/src/lib/constant.tsapps/cli/src/helpers/core/create-readme.tsapps/cli/src/utils/compatibility-rules.tsapps/cli/src/helpers/core/env-setup.tsapps/cli/src/helpers/core/template-manager.tsapps/cli/src/utils/compatibility.tsapps/cli/src/helpers/core/post-installation.tsapps/cli/src/types.tsapps/cli/src/helpers/core/auth-setup.tsapps/cli/src/helpers/core/api-setup.tsapps/cli/src/helpers/core/payments-setup.tsapps/cli/src/prompts/frontend.ts
**/*.{js,jsx,ts,tsx,mjs,cjs}
📄 CodeRabbit inference engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
**/*.{js,jsx,ts,tsx,mjs,cjs}: Do not use dotenv; Bun auto-loads .env
UseBun.serve()for HTTP/WebSockets; do not useexpress
Usebun:sqlitefor SQLite; do not usebetter-sqlite3
UseBun.redisfor Redis; do not useioredis
UseBun.sqlfor Postgres; do not usepgorpostgres.js
Use built-inWebSocket; do not usews
PreferBun.fileovernode:fsreadFile/writeFile
UseBun.$instead ofexecafor shelling out
Files:
apps/cli/test/frontend.test.tsapps/web/src/lib/constant.tsapps/cli/src/helpers/core/create-readme.tsapps/cli/src/utils/compatibility-rules.tsapps/cli/src/helpers/core/env-setup.tsapps/cli/src/helpers/core/template-manager.tsapps/cli/src/utils/compatibility.tsapps/cli/src/helpers/core/post-installation.tsapps/cli/src/types.tsapps/cli/src/helpers/core/auth-setup.tsapps/cli/src/helpers/core/api-setup.tsapps/cli/src/helpers/core/payments-setup.tsapps/cli/src/prompts/frontend.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/better-t-stack-repo.mdc)
Define functions using the standard function declaration syntax, not arrow functions.
Files:
apps/cli/test/frontend.test.tsapps/web/src/lib/constant.tsapps/cli/src/helpers/core/create-readme.tsapps/cli/src/utils/compatibility-rules.tsapps/cli/src/helpers/core/env-setup.tsapps/cli/src/helpers/core/template-manager.tsapps/cli/src/utils/compatibility.tsapps/cli/src/helpers/core/post-installation.tsapps/cli/src/types.tsapps/cli/src/helpers/core/auth-setup.tsapps/cli/src/helpers/core/api-setup.tsapps/cli/src/helpers/core/payments-setup.tsapps/cli/src/prompts/frontend.ts
**/*.{hbs,handlebars}
📄 CodeRabbit inference engine (.cursor/rules/better-t-stack-repo.mdc)
In Handlebars templates, avoid generic if/else blocks; write explicit conditions (e.g., if (eq orm "prisma") and else if (eq orm "drizzle")).
Files:
apps/cli/templates/frontend/astro/src/pages/index.astro.hbsapps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbsapps/cli/templates/frontend/astro/astro.config.mjs.hbsapps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbsapps/cli/templates/frontend/astro/tsconfig.json.hbsapps/cli/templates/frontend/astro/package.json.hbsapps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs
🧠 Learnings (1)
📚 Learning: 2025-06-08T17:57:33.083Z
Learnt from: Vijayabaskar56
PR: AmanVarshney01/create-better-t-stack#310
File: apps/cli/templates/frontend/angular/src/app.component.html:1-7
Timestamp: 2025-06-08T17:57:33.083Z
Learning: The Angular frontend template uses Tailwind CSS v4, which doesn't require a traditional tailwind.config.js configuration file.
Applied to files:
apps/cli/templates/frontend/astro/src/styles/global.css
🧬 Code graph analysis (1)
apps/cli/src/helpers/core/template-manager.ts (1)
apps/cli/src/constants.ts (1)
PKG_ROOT(7-7)
🔇 Additional comments (43)
apps/cli/src/prompts/frontend.ts (1)
58-62: LGTM! Astro option integrated correctly.The new Astro frontend option follows the established pattern with proper type safety using
as const, consistent structure, and an appropriate descriptive hint.apps/cli/templates/frontend/astro/src/styles/global.css (1)
1-5: LGTM! Tailwind v4 integration is clean.The direct
@import 'tailwindcss'follows Tailwind v4's approach, which aligns with how other frontend templates in this project use Tailwind v4 (without traditional config files). The utility classes applied to body provide sensible dark-themed defaults.apps/cli/templates/frontend/astro/_gitignore (1)
1-24: LGTM! Comprehensive gitignore for Astro projects.The gitignore template appropriately covers Astro-specific artifacts (dist/, .astro/), standard Node.js patterns (node_modules/, logs), environment variables, and common developer environment files. The organization with section comments enhances readability.
apps/cli/src/utils/compatibility-rules.ts (1)
36-36: LGTM! Error message updated to include Astro.The error message now correctly lists "astro" among the web framework options, maintaining consistency with the newly added Astro frontend support.
apps/cli/templates/frontend/astro/tsconfig.json.hbs (3)
5-8: Project reference configuration looks correct.The conditional project reference to
../serverwhen using oRPC enables proper type sharing and project structure for the monorepo setup.
10-13: JSX configuration is appropriate for oRPC with React.The conditional JSX settings correctly enable React JSX transform when oRPC is selected, which aligns with oRPC's React integration requirements.
14-20: Path aliases are well-structured.The path mappings provide clean imports for common directories and follow Astro conventions.
apps/cli/templates/frontend/astro/astro.config.mjs.hbs (4)
1-5: Conditional imports follow best practices.The Handlebars conditional correctly imports React integration only when oRPC is selected, keeping the bundle lean for non-oRPC setups.
8-10: Tailwind integration via Vite plugin is correct.Using
@tailwindcss/viteas a Vite plugin is the recommended approach for Tailwind v4 with Astro.
11-13: React integration properly gated behind oRPC check.The conditional integration of React is consistent with the oRPC requirement and matches the TypeScript configuration.
14-14: Static output mode is correct for this template.The configuration correctly uses
output: 'static'for this Astro template. When oRPC is selected, theOrpcApiStatuscomponent is rendered with theclient:only="react"directive, meaning it hydrates and executes entirely in the browser. The component uses@tanstack/react-queryto make client-side API calls after the page loads—this is the standard JAMstack pattern where static HTML is served and API interactions happen client-side.oRPC is a client-side library and does not require SSR. The static output mode is intentional and appropriate for this use case.
apps/cli/templates/frontend/astro/package.json.hbs (5)
10-16: Astro scripts are well-configured.The npm scripts provide all standard Astro workflows (dev, build, preview) and include a pass-through
astrocommand for CLI access.
22-30: Conditional oRPC dependencies are properly structured.The Handlebars conditional correctly adds React, oRPC client, and TanStack Query dependencies only when the oRPC API is selected. The comma placement ensures valid JSON syntax.
34-35: React Query devtools appropriately in devDependencies.The conditional inclusion of TanStack React Query devtools in devDependencies (only for oRPC setups) follows best practices for development tooling.
7-9: Node.js 22 requirement is appropriate.Node.js 22 is the current LTS version (codename "Jod"), with LTS status beginning October 29, 2024. Requiring the current LTS version for a new project template is standard practice and aligns with recommended deployment environments.
Likely an incorrect or invalid review comment.
22-22: Zod version 4.1.5 is valid.The latest stable Zod version is 4.1.11 (released Sep 20, 2025), confirming that version 4.1.5 specified in the package.json is legitimate. The caret range
^4.1.5will correctly allow updates through the 4.x series.apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs (5)
1-6: Imports are correctly structured for oRPC and TanStack Query integration.The imports cover all necessary oRPC client utilities, plugins, and TanStack Query dependencies.
8-14: QueryClient configuration with error handling is appropriate.The QueryClient setup with a global error handler in QueryCache provides consistent error logging across all queries.
16-31: RPCLink configuration enables batching and error interception.The RPCLink setup correctly:
- Uses Vite environment variables for the server URL
- Enables request batching via BatchLinkPlugin
- Adds error logging via onError interceptor
33-35: Client and utility exports are properly typed.The exports provide strongly-typed oRPC client and TanStack Query utilities, enabling type-safe API calls in the Astro frontend.
6-6: The relative path is correct and consistent with the generated project structure.The path
"../../../server/src/routers/index"is accurate for the generated monorepo layout whereweb/andserver/are sibling directories. Fromweb/src/lib/orpc.ts, three levels up (../../../) reaches the monorepo root, then navigates toserver/src/routers/index. This pattern is consistently used across all oRPC web frontend templates (Astro, Svelte, Solid, React, Nuxt), and theAppRouterClienttype is correctly exported fromserver/src/routers/index.ts.apps/cli/src/helpers/core/create-readme.ts (1)
177-177: LGTM! Astro frontend detection implemented correctly.The Astro frontend detection follows the established pattern used for other frameworks, and the positioning in the stack description (after Nuxt, before SolidJS) is logical.
Also applies to: 194-195
apps/cli/src/helpers/core/post-installation.ts (1)
90-101: LGTM! Astro correctly identified as web frontend.The addition of "astro" to the hasWeb check ensures that Astro projects will receive appropriate web frontend post-installation instructions, including the frontend URL and other web-specific setup guidance.
apps/cli/src/helpers/core/payments-setup.ts (1)
30-41: LGTM! Polar payments setup correctly handles Astro.The addition ensures that Astro projects with Polar payments will receive the necessary client-side
@polar-sh/better-authdependency, consistent with other web frameworks.apps/cli/src/utils/compatibility.ts (1)
3-12: LGTM! Astro successfully added to web frameworks constant.The addition of "astro" to
WEB_FRAMEWORKSis correct and properly integrated. The constant is used in:
hasWebFrontend()- checks if frontends include web frameworksisWebFrontend()- validates individual frontend types- Error messaging in compatibility validation
The error message in
compatibility-rules.ts:36already includes "astro", confirming this is part of a coordinated update.Minor inconsistency (optional): The array order differs slightly from the error message order (react-router/tanstack-start positions swapped), though this doesn't affect functionality.
apps/cli/test/frontend.test.ts (1)
21-21: Astro + tRPC compatibility confirmed.The test configuration correctly uses tRPC as the default API for Astro. The validation logic in
apps/cli/src/utils/compatibility-rules.ts(lines 114-126) explicitly restricts tRPC only for Nuxt, Svelte, and Solid frontends. Astro is not in this incompatible list, so it supports all API options including tRPC. The test setup is intentional and accurate.apps/web/src/lib/constant.ts (1)
83-90: LGTM! Astro option added correctly.The Astro entry follows the established pattern for webFrontend options with appropriate metadata, description, and styling. The gradient color choice is distinct and the default value is appropriately set to false.
apps/cli/src/helpers/core/auth-setup.ts (1)
112-123: LGTM! Astro correctly included in web frontend detection.The addition of "astro" to the
hasWebFrontendcheck ensures that authentication dependencies are properly configured when Astro is selected as a web frontend. This is consistent with the treatment of other web frameworks.apps/cli/src/types.ts (1)
23-38: LGTM! Astro enum value added correctly.The addition of "astro" to the
FrontendSchemaenum is well-placed and enables type-safe Astro support throughout the codebase. The positioning is logical, keeping web frameworks grouped together.apps/cli/src/helpers/core/env-setup.ts (2)
109-120: LGTM! Astro detection integrated properly.The
hasAstroconstant and its inclusion inhasWebFrontendfollows the established pattern for other web frameworks. This ensures Astro projects receive proper environment variable configuration.
293-295: LGTM! Correct CORS origin for Astro's dev server.Port 4321 is Astro's default development server port, so this CORS origin configuration is accurate. The conditional logic follows the same pattern as other framework-specific CORS settings.
apps/cli/templates/frontend/astro/src/pages/index.astro.hbs (4)
2-8: TODO comment is appropriately placed.The placeholder for Convex integration in Astro is clearly marked with a TODO. This is a reasonable deferral given the PR's focus on base Astro support with oRPC integration.
34-34: Correct use of Astro's client directive for React component.The
client:only="react"directive is the appropriate way to hydrate a React component in Astro, ensuring it only renders on the client side. This is necessary for the OrpcApiStatus component.
12-26: ASCII art title is visually consistent.The TITLE_TEXT constant contains properly formatted ASCII art that matches the branding style. Good use of a constant to keep the template markup clean.
5-7: Import path resolves correctly.The template-manager's
setupFrontendTemplatesfunction copies the oRPC Astro component template fromtemplates/api/orpc/web/astro/src/components/orpc-status.tsx.hbstoapps/web/src/components/orpc-status.tsx(stripping the.hbsextension). The import path'../components/orpc-status'insrc/pages/index.astrocorrectly resolves to this location.Likely an incorrect or invalid review comment.
apps/cli/src/helpers/core/template-manager.ts (3)
70-70: LGTM!The
hasAstroWebflag is correctly derived fromcontext.frontend.includes("astro")and follows the established pattern for other framework detection flags.
78-78: LGTM!The condition correctly extends web app setup to include Astro alongside the existing frameworks.
144-160: LGTM!The Astro template setup block correctly mirrors the pattern established by Nuxt, Svelte, and Solid. The structure properly:
- Copies base Astro templates from
templates/frontend/astro- Conditionally copies ORPC-specific API templates when
!isConvex && context.api === "orpc"- Maintains consistency with the else-if chain ordering
apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs (2)
5-32: LGTM!The
ApiStatuscomponent correctly uses theuseQueryhook with ORPC query options and provides clear visual feedback for connection status. The loading, connected, and disconnected states are well-handled.
34-40: LGTM!The
OrpcApiStatuswrapper correctly provides theQueryClientProvidercontext for theApiStatuscomponent, enabling it to work as a client-only component in Astro.apps/cli/src/helpers/core/api-setup.ts (2)
28-28: LGTM!The
hasAstroWebflag is correctly added to the return type and implementation ofgetFrontendType, following the established pattern for other framework detection flags.Also applies to: 44-44
113-121: LGTM!The Astro web dependency resolution is correctly implemented for ORPC. Using
@tanstack/react-queryalongside ORPC dependencies makes sense since Astro uses React for client-side components (as evidenced by theclient:only="react"directive in the templates). The dependency list mirrors the pattern used for React-based frontends.apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs (1)
5-8: Use TypeScript type alias instead of interface.The coding guidelines specify using type aliases instead of interface declarations for TypeScript.
As per coding guidelines.
Apply this diff:
-interface Props { +type Props = { title?: string | undefined; description?: string | undefined; -} +};⛔ Skipped due to learnings
Learnt from: CR PR: AmanVarshney01/create-better-t-stack#0 File: .cursor/rules/better-t-stack-repo.mdc:0-0 Timestamp: 2025-09-11T04:31:24.508Z Learning: Applies to **/*.{ts,tsx} : Use TypeScript type aliases instead of interface declarations.
devzom
force-pushed
the
feature/201-add-astro-framework
branch
from
597ce08 to
b6e4975
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/cli/templates/frontend/astro/tsconfig.json.hbs (1)
5-8: Remove trailing whitespace.Line 7 has trailing whitespace after
"../server"which should be removed for consistency.Apply this diff:
- { "path": "../server" } + { "path": "../server" }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs(1 hunks)apps/cli/templates/frontend/astro/tsconfig.json.hbs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{hbs,handlebars}
📄 CodeRabbit inference engine (.cursor/rules/better-t-stack-repo.mdc)
In Handlebars templates, avoid generic if/else blocks; write explicit conditions (e.g., if (eq orm "prisma") and else if (eq orm "drizzle")).
Files:
apps/cli/templates/frontend/astro/tsconfig.json.hbsapps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs
🔇 Additional comments (7)
apps/cli/templates/frontend/astro/tsconfig.json.hbs (3)
9-9: Typo fixed - LGTM!The previous critical typo "comilerOptions" has been corrected to "compilerOptions". TypeScript will now properly recognize and apply the compiler configuration.
10-13: LGTM!The conditional JSX configuration for oRPC with React is correct. The explicit Handlebars condition follows the coding guidelines, and the compiler options properly configure React JSX for Astro integration.
14-20: LGTM!The path aliases configuration follows Astro conventions and provides a clean way to import from common directories. The structure is well-organized and consistent.
apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs (4)
1-3: LGTM! Standard CSS import.The global CSS import follows Astro conventions correctly.
5-11: LGTM! Props interface and defaults are well-defined.The Props interface correctly defines optional properties, and the default description provides a sensible fallback.
14-22: LGTM! The HTML head structure is correct.The meta tags and title properly mix Handlebars template variables (e.g.,
{{projectName}}) with Astro runtime expressions (e.g.,${description}and{title}). The syntax correctly separates:
- CLI generation-time substitution:
{{projectName}}- Astro runtime interpolation:
${description}and{title}Note: A previous review comment raised concerns about line 18, but the current implementation correctly uses
${description}to reference the Astro prop rather than a Handlebars variable.
23-26: LGTM! Body structure follows Astro conventions.The
<slot />element correctly allows child content to be injected into this layout.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs (2)
8-14: LGTM! Consider enhancing error logging for production.The QueryClient setup with error handling is correct. For production applications, consider logging additional error details (stack trace, context) or integrating with a monitoring service.
16-31: Fix formatting inconsistency.The RPCLink configuration is correct. However, there's a minor formatting inconsistency on line 30 with inconsistent indentation before the closing bracket.
Apply this diff to fix the indentation:
interceptors: [ onError((error) => { console.error(`RPC Error: ${error.message}`, error) }) - ], + ], });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs(1 hunks)apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs(1 hunks)apps/cli/templates/frontend/astro/public/robots.txt(1 hunks)apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs(1 hunks)apps/cli/templates/frontend/astro/tsconfig.json.hbs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs
- apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs
- apps/cli/templates/frontend/astro/public/robots.txt
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{hbs,handlebars}
📄 CodeRabbit inference engine (.cursor/rules/better-t-stack-repo.mdc)
In Handlebars templates, avoid generic if/else blocks; write explicit conditions (e.g., if (eq orm "prisma") and else if (eq orm "drizzle")).
Files:
apps/cli/templates/frontend/astro/tsconfig.json.hbsapps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs
🔇 Additional comments (7)
apps/cli/templates/frontend/astro/tsconfig.json.hbs (4)
1-4: LGTM: Base configuration is correct.The extends, include, and exclude settings are appropriate for an Astro project with strict TypeScript configuration.
9-13: LGTM: Typo fixed and JSX configuration is appropriate.The critical typo "comilerOptions" from the previous review has been correctly fixed to "compilerOptions". The conditional JSX settings for React are appropriate when using oRPC with Astro.
14-21: LGTM: Path aliases are well-structured.The path aliases follow standard conventions and provide clear, organized imports for Astro project components and assets.
5-8: No changes needed:../serverpath is correct.apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs (3)
33-33: LGTM!The client creation with explicit type annotation ensures type safety and correctly integrates with the configured RPC link.
35-35: LGTM!The TanStack Query utilities wrapper correctly integrates the ORPC client for use in React components within Astro.
6-6: Verify relative import path resolution
Ensure the import../../../server/src/routers/indexcorrectly points to your server router definitions after scaffolding—confirm thatindex.tsexists atserver/src/routersrelative to the generated Astro client directory.
devzom
force-pushed
the
feature/201-add-astro-framework
branch
from
b6e4975 to
8ebf95f
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs (1)
19-24: Single always-true batch group is overly permissive.The BatchLinkPlugin has only one group with
condition: () => true, meaning all requests are always batched together. Consider whether this is the intended behavior or if requests should be grouped more selectively based on:
- Request destination
- Priority/urgency
- Timing constraints
If selective batching is needed, consider:
new BatchLinkPlugin({ groups: [ { // High-priority requests condition: (context) => context.priority === 'high', context: {}, }, { // Normal requests (default) condition: () => true, context: {}, } ], })If batching all requests together is intentional (e.g., for simplicity or performance), then the current code is fine.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
apps/cli/templates/frontend/astro/public/favicon.svgis excluded by!**/*.svg
📒 Files selected for processing (23)
apps/cli/src/helpers/core/api-setup.ts(3 hunks)apps/cli/src/helpers/core/auth-setup.ts(1 hunks)apps/cli/src/helpers/core/create-readme.ts(2 hunks)apps/cli/src/helpers/core/env-setup.ts(3 hunks)apps/cli/src/helpers/core/payments-setup.ts(1 hunks)apps/cli/src/helpers/core/post-installation.ts(1 hunks)apps/cli/src/helpers/core/template-manager.ts(2 hunks)apps/cli/src/prompts/frontend.ts(1 hunks)apps/cli/src/types.ts(1 hunks)apps/cli/src/utils/compatibility-rules.ts(1 hunks)apps/cli/src/utils/compatibility.ts(1 hunks)apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs(1 hunks)apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs(1 hunks)apps/cli/templates/frontend/astro/_gitignore(1 hunks)apps/cli/templates/frontend/astro/astro.config.mjs.hbs(1 hunks)apps/cli/templates/frontend/astro/package.json.hbs(1 hunks)apps/cli/templates/frontend/astro/public/robots.txt(1 hunks)apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs(1 hunks)apps/cli/templates/frontend/astro/src/pages/index.astro.hbs(1 hunks)apps/cli/templates/frontend/astro/src/styles/global.css(1 hunks)apps/cli/templates/frontend/astro/tsconfig.json.hbs(1 hunks)apps/cli/test/frontend.test.ts(2 hunks)apps/web/src/lib/constant.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (15)
- apps/cli/src/helpers/core/post-installation.ts
- apps/cli/templates/frontend/astro/package.json.hbs
- apps/cli/test/frontend.test.ts
- apps/cli/templates/frontend/astro/_gitignore
- apps/cli/templates/frontend/astro/public/robots.txt
- apps/cli/src/helpers/core/create-readme.ts
- apps/cli/templates/frontend/astro/src/styles/global.css
- apps/web/src/lib/constant.ts
- apps/cli/src/helpers/core/payments-setup.ts
- apps/cli/src/helpers/core/auth-setup.ts
- apps/cli/src/utils/compatibility.ts
- apps/cli/templates/frontend/astro/src/layouts/Layout.astro.hbs
- apps/cli/src/prompts/frontend.ts
- apps/cli/templates/frontend/astro/tsconfig.json.hbs
- apps/cli/src/helpers/core/env-setup.ts
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/convex_rules.mdc)
**/*.{ts,tsx}: Use Id from './_generated/dataModel' to type document ids (e.g., Id<'users'>)
Ensure Record key/value types align with validators (e.g., v.record(v.id('users'), v.string()) => Record<Id<'users'>, string>)
Be strict with types for document ids; prefer Id<'table'> over string
Use 'as const' for string literals in discriminated unions
When using Array and Record types, declare with explicit generic types (e.g., const arr: Array = ...)
**/*.{ts,tsx}: Use TypeScript type aliases instead of interface declarations.
Do not use explicit return types in TypeScript.
Files:
apps/cli/src/helpers/core/template-manager.tsapps/cli/src/types.tsapps/cli/src/utils/compatibility-rules.tsapps/cli/src/helpers/core/api-setup.ts
**/*.{js,jsx,ts,tsx,mjs,cjs}
📄 CodeRabbit inference engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
**/*.{js,jsx,ts,tsx,mjs,cjs}: Do not use dotenv; Bun auto-loads .env
UseBun.serve()for HTTP/WebSockets; do not useexpress
Usebun:sqlitefor SQLite; do not usebetter-sqlite3
UseBun.redisfor Redis; do not useioredis
UseBun.sqlfor Postgres; do not usepgorpostgres.js
Use built-inWebSocket; do not usews
PreferBun.fileovernode:fsreadFile/writeFile
UseBun.$instead ofexecafor shelling out
Files:
apps/cli/src/helpers/core/template-manager.tsapps/cli/src/types.tsapps/cli/src/utils/compatibility-rules.tsapps/cli/src/helpers/core/api-setup.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/better-t-stack-repo.mdc)
Define functions using the standard function declaration syntax, not arrow functions.
Files:
apps/cli/src/helpers/core/template-manager.tsapps/cli/src/types.tsapps/cli/src/utils/compatibility-rules.tsapps/cli/src/helpers/core/api-setup.ts
**/*.{hbs,handlebars}
📄 CodeRabbit inference engine (.cursor/rules/better-t-stack-repo.mdc)
In Handlebars templates, avoid generic if/else blocks; write explicit conditions (e.g., if (eq orm "prisma") and else if (eq orm "drizzle")).
Files:
apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbsapps/cli/templates/frontend/astro/astro.config.mjs.hbsapps/cli/templates/frontend/astro/src/pages/index.astro.hbsapps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs
🧬 Code graph analysis (1)
apps/cli/src/helpers/core/template-manager.ts (1)
apps/cli/src/constants.ts (1)
PKG_ROOT(7-7)
🔇 Additional comments (14)
apps/cli/src/utils/compatibility-rules.ts (1)
36-36: LGTM! Error message correctly updated.The error message now includes "astro" in the list of mutually exclusive web frameworks, consistent with the addition of Astro as a supported frontend option.
apps/cli/src/types.ts (1)
30-30: LGTM! Astro frontend type added correctly.The "astro" enum member is properly added to FrontendSchema, enabling Astro as a selectable frontend option throughout the CLI.
apps/cli/src/helpers/core/template-manager.ts (3)
70-70: LGTM! Astro frontend detection added.The
hasAstroWebflag correctly identifies when Astro is selected as a frontend, consistent with the pattern used for other frameworks.
78-78: LGTM! Condition updated to include Astro.The web app directory creation condition now properly accounts for Astro frontends.
144-160: LGTM! Astro frontend setup follows established patterns.The Astro frontend branch:
- Correctly copies base Astro templates
- Conditionally includes ORPC API templates when appropriate
- Follows the same structure as Nuxt, Svelte, and Solid branches
- Properly checks for directory existence before copying
apps/cli/templates/frontend/astro/src/pages/index.astro.hbs (1)
34-34: LGTM! React component integration in Astro.The
client:only="react"directive correctly tells Astro to:
- Skip server-side rendering for this component
- Hydrate it only on the client using React
- Necessary for the OrpcApiStatus component that uses React hooks
apps/cli/templates/api/orpc/web/astro/src/components/orpc-status.tsx.hbs (2)
33-39: LGTM! QueryClientProvider wrapper.The
OrpcApiStatuscomponent correctly wrapsApiStatuswithQueryClientProvider, enabling TanStack Query functionality for the health check.
4-31: Use function declaration syntax.The
ApiStatuscomponent uses an arrow function, but coding guidelines require standard function declarations.Apply this diff:
-function ApiStatus() { +function ApiStatus() { const healthCheck = useQuery(orpc.healthCheck.queryOptions()); return ( <section className="rounded-lg border p-4"> <h2 className="mb-2 font-medium">API Status</h2> <div className="flex items-center gap-2"> <div className={`h-2 w-2 rounded-full ${ healthCheck.data ? "bg-green-500" : "bg-red-500" }`} ></div> <span className="text-muted-foreground text-sm"> {healthCheck.isLoading ? "Checking..." : healthCheck.data ? "Connected" : "Disconnected"} </span> </div> {healthCheck.data && ( <div className="mt-2 text-sm text-green-600"> Response: {JSON.stringify(healthCheck.data)} </div> )} </section> ); }Note: The code already uses function declaration syntax (
function ApiStatus()), so this is actually correct. Disregard this comment.apps/cli/src/helpers/core/api-setup.ts (2)
28-28: LGTM! Astro frontend type detection added.The
hasAstroWebflag is correctly added to the frontend type detection, consistent with other framework flags.Also applies to: 44-44
113-122: LGTM! Astro ORPC dependencies configured correctly.The dependency configuration for Astro + ORPC:
- Uses React Query (appropriate since Astro can use React components)
- Includes ORPC TanStack Query adapter
- Includes React Query devtools for development
- Follows the same pattern as other frontend integrations
apps/cli/templates/api/orpc/web/astro/src/lib/orpc.ts.hbs (2)
33-33: Remove explicit type annotation.The variable has an explicit type annotation
AppRouterClient, but coding guidelines state: "Do not use explicit return types in TypeScript." This applies to variable declarations as well when the type can be inferred.Apply this diff:
-export const client: AppRouterClient = createORPCClient(link); +export const client = createORPCClient(link) as AppRouterClient;Actually, if we're following "no explicit types" strictly, it should just be:
-export const client: AppRouterClient = createORPCClient(link); +export const client = createORPCClient(link);However, this might lose important type information. The type assertion approach (
as AppRouterClient) preserves the type while avoiding the explicit annotation syntax.Based on coding guidelines.
Likely an incorrect or invalid review comment.
6-6: Dismiss import path warning in CLI template. The../../../server/src/routers/indeximport is correct in the generated project’s layout (the CLI template includes a parallelserverfolder), not the CLI repo’s structure.Likely an incorrect or invalid review comment.
apps/cli/templates/frontend/astro/astro.config.mjs.hbs (2)
3-5: Use explicit Handlebars conditions.The template uses a generic
ifblock. Per coding guidelines, use explicit conditions in Handlebars templates instead of generic if/else blocks.Apply this diff:
-{{#if (eq api "orpc")}} +{{#if (eq api "orpc")}} import react from '@astrojs/react'; +{{else if (eq api "trpc")}} +// Add trpc-specific imports if needed +{{else if (eq api "none")}} +// No API-specific imports {{/if}}However, if there are truly no alternatives to handle and ORPC is the only case requiring imports, then the current structure is acceptable. Consider whether future API types might need different imports here.
Based on coding guidelines.
⛔ Skipped due to learnings
Learnt from: CR PR: AmanVarshney01/create-better-t-stack#0 File: .cursor/rules/better-t-stack-repo.mdc:0-0 Timestamp: 2025-09-11T04:31:24.508Z Learning: Applies to **/*.{hbs,handlebars} : In Handlebars templates, avoid generic if/else blocks; write explicit conditions (e.g., if (eq orm "prisma") and else if (eq orm "drizzle")).
11-13: Use explicit Handlebars conditions for integrations.Similar to the import section, use explicit conditions instead of a generic if block.
Apply this diff:
- {{#if (eq api "orpc")}} + {{#if (eq api "orpc")}} integrations: [react()], + {{else if (eq api "trpc")}} + integrations: [], + {{else}} + integrations: [], {{/if}}Or remove the conditional wrapper entirely if non-ORPC cases don't need an integrations array.
Based on coding guidelines.
⛔ Skipped due to learnings
Learnt from: CR PR: AmanVarshney01/create-better-t-stack#0 File: .cursor/rules/better-t-stack-repo.mdc:0-0 Timestamp: 2025-09-11T04:31:24.508Z Learning: Applies to **/*.{hbs,handlebars} : In Handlebars templates, avoid generic if/else blocks; write explicit conditions (e.g., if (eq orm "prisma") and else if (eq orm "drizzle")).
| {{#if (eq backend "convex")}} | ||
| // TODO: Add Convex integration for Astro | ||
| {{else}} | ||
| {{#if (eq api "orpc")}} | ||
| import { OrpcApiStatus } from '../components/orpc-status'; | ||
| {{/if}} | ||
| {{/if}} |
There was a problem hiding this comment.
Address the TODO for Convex integration.
The TODO comment indicates incomplete Convex integration for Astro. This means users selecting Astro with Convex backend will have an incomplete setup.
Do you want me to:
- Generate a verification script to check if Convex+Astro combinations are blocked at the prompt/validation level?
- Open a tracking issue for implementing Convex integration?
🤖 Prompt for AI Agents
In apps/cli/templates/frontend/astro/src/pages/index.astro.hbs around lines 2-8,
the TODO for Convex integration leaves the Astro+Convex combination incomplete;
replace the TODO with a clear user-facing fallback that either (a) displays a
descriptive message in the template stating "Convex integration for Astro is not
yet supported — see ISSUE_URL for progress" and does not attempt to import
Convex-specific components, and (b) create a GitHub tracking issue and add its
URL into the message; additionally add a small validation helper (or script) in
the CLI templates validation flow to detect when backend=="convex" and
frontend=="astro" and surface a blocking error or warning during project
generation pointing to the tracking issue.
|
Thanks @devzom I'll take a look 🫡 |
2 participants
Resolve #201
Introduce support for the Astro framework, including configuration and layout setup. Implement optional static rendering and integrate oRPC for API status management.
Update frontend choice options and enhance the overall project structure.
Important
This PR doesn't bring the option to handle multi-repo, ex picking Next.js for dashboard and Astro as marketing website. For this there's should be a follow up PR.
Summary by CodeRabbit