feat(example): add NestJs + Next.js + ShadCN example #10792
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@MRdevX is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Additional Comments:
examples/with-nestjs-nextjs-shadcn/packages/ui (lines 1-1):
The UI package contains duplicate ESLint configuration files which can cause conflicts and confusion.
View Details
📝 Patch Details
diff --git a/examples/with-nestjs-nextjs-shadcn/packages/ui/eslint.config.js b/examples/with-nestjs-nextjs-shadcn/packages/ui/eslint.config.js
deleted file mode 100644
index fe059de7f..000000000
--- a/examples/with-nestjs-nextjs-shadcn/packages/ui/eslint.config.js
+++ /dev/null
@@ -1,4 +0,0 @@
-import { config } from '@repo/eslint-config/react-internal';
-
-/** @type {import("eslint").Linter.Config} */
-export default config;
Analysis
The packages/ui directory contains both eslint.config.js and eslint.config.mjs files with identical content. Having duplicate configuration files can lead to:
- Confusion about which configuration is actually being used
- Potential conflicts if they diverge in the future
- Maintenance overhead of keeping both files in sync
- Inconsistency with the rest of the monorepo structure
ESLint will typically use the first configuration file it finds based on its resolution order, but having both files present makes the setup unclear and potentially error-prone.
Recommendation
Remove one of the duplicate ESLint configuration files. Since the project appears to use ES modules (indicated by the .mjs extension usage elsewhere), keep eslint.config.mjs and delete eslint.config.js.
Alternatively, if CommonJS is preferred, keep eslint.config.js and delete eslint.config.mjs.
| import { ThemeProvider as NextThemesProvider } from "next-themes"; | ||
|
|
||
| interface ProvidersProps { | ||
| children: any; |
There was a problem hiding this comment.
| children: any; | |
| children: React.ReactNode; |
The children prop in ProvidersProps interface is typed as any instead of proper React types, reducing type safety.
View Details
Analysis
The ProvidersProps interface defines the children prop as any, which defeats the purpose of TypeScript's type checking. This removes type safety and can lead to runtime errors if incorrect values are passed as children.
The correct type for React children should be React.ReactNode, which properly represents any valid React child element including strings, numbers, JSX elements, arrays, fragments, and null/undefined values.
Using any also means developers won't get proper IntelliSense suggestions and type checking when using this component.
Recommendation
Update the interface to use proper React types:
interface ProvidersProps {
children: React.ReactNode;
}This provides proper type safety while accepting all valid React children types.
| import { Link } from 'links/entities/link.entity'; | ||
|
|
||
| import { CreateLinkDto } from 'links/dto/create-link.dto'; | ||
| import { UpdateLinkDto } from 'links/dto/update-link.dto'; |
There was a problem hiding this comment.
Import paths are missing the required ./ prefix for relative imports in the shared API package index file.
View Details
Analysis
The imports in packages/api/src/index.ts are using relative paths without the proper ./ prefix. TypeScript and Node.js require relative imports to start with ./ or ../ to distinguish them from node_modules imports. The current imports 'links/entities/link.entity' and 'links/dto/create-link.dto' should be './links/entities/link.entity' and './links/dto/create-link.dto' respectively.
This will cause TypeScript compilation errors when the package is built, as the module resolver won't be able to find these files. The error would typically be "Cannot find module 'links/entities/link.entity'" or similar.
Recommendation
Update the import statements to use proper relative paths:
import { Link } from './links/entities/link.entity';
import { CreateLinkDto } from './links/dto/create-link.dto';
import { UpdateLinkDto } from './links/dto/update-link.dto';|
Hey, @MRdevX, thanks for the PR! According to our examples guidelines, we try to keep examples scoped to one technology at a time. The combination of Nest.js and ShadCN shown here is great, but not scoped in such a way that I'll be able to take this PR. Seeing as we already have a Nest.js example and docs for shadcn/ui that point to the official example, I'm going to close this PR. Thanks again for contributing and we welcome you back to contribute again as soon as you'd like! |
Description
This PR adds a comprehensive Next.js + NestJS + ShadCN template to the Turborepo examples, showcasing a modern full-stack monorepo architecture with the latest technologies and best practices.
🎯 What's Included
Full-Stack Architecture:
Key Features:
@repo/uipackage with ShadCN@repo/apipackage with DTOs and entitiesProject Structure:
UI Components Included:
Technical Highlights:
@themedirectives and@sourcescanningtailwind.config.jsneeded🖼️ Screenshots
The template includes a beautiful demo page showcasing:
Testing Instructions
Prerequisites
Quick Start
What to Test
Development Experience:
UI Components:
Build System:
# Test builds pnpm build pnpm lint pnpm typecheckMonorepo Features:
@repo/ui,@repo/api)Component Library:
Expected Results
This template serves as a starting point for full-stack applications using modern web technologies and Turborepo's powerful monorepo capabilities.