feat: Setup Monorepo foundation #1
Conversation
- Add pnpm 10.27.0 workspace configuration - Add Turborepo 2.7.2 with task pipeline and caching - Add shared TypeScript configs (strict mode) - Add ESLint v9 flat config with TypeScript rules - Add @devradar/shared package with types and validators - Add Docker Compose for Redis 8 + PostgreSQL 17 - Add GitHub Actions CI/CD workflows - Add Husky pre-commit hooks
|
Warning Rate limit exceeded@senutpal has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 9 minutes and 20 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds foundational monorepo infrastructure: workspace and build tooling, CI/CD and dependabot workflows, editor/formatting and lint configs, a shared package with types/constants/validators, Docker compose for local services, and documentation including environment sample and README. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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 |
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
|
| Filename | Overview |
|---|---|
| package.json | Added monorepo root with pnpm@10.27.0, Turborepo, comprehensive scripts for building, testing, linting, and Husky pre-commit hooks |
| turbo.json | Configured Turborepo with task dependencies, caching strategy, and persistent dev tasks |
| docker-compose.yml | Added Redis 8 and PostgreSQL 17 services with healthchecks, optional management tools (pgAdmin, Redis Commander) |
| .github/workflows/ci.yml | Comprehensive CI pipeline with build, test, lint, type-check, and security scanning (CodeQL + pnpm audit) |
| packages/shared/src/types.ts | Well-documented TypeScript types for user status, WebSocket messages, activity tracking, and API responses |
| packages/shared/src/validators.ts | Zod schemas with proper validation rules for all shared types, runtime type safety |
| packages/tsconfig/base.json | Strict TypeScript configuration with all safety flags enabled (noUncheckedIndexedAccess, exactOptionalPropertyTypes, etc.) |
| packages/eslint-config/base.js | ESLint v9 flat config with strict TypeScript rules, import ordering, and consistent code style enforcement |
Sequence Diagram
sequenceDiagram
participant Dev as Developer
participant Git as Git
participant Husky as Husky Hook
participant LS as lint-staged
participant ESLint as ESLint
participant Prettier as Prettier
participant CI as GitHub Actions
participant Turbo as Turborepo
participant Tests as Test Suite
Dev->>Git: git commit
Git->>Husky: trigger pre-commit
Husky->>LS: run lint-staged
LS->>ESLint: lint staged files
ESLint-->>LS: validation result
LS->>Prettier: format staged files
Prettier-->>LS: formatting applied
LS-->>Husky: success
Husky-->>Git: allow commit
Git-->>Dev: commit created
Dev->>Git: git push
Git->>CI: trigger CI workflow
CI->>Turbo: pnpm install --frozen-lockfile
CI->>Turbo: format:check
CI->>Turbo: lint (with cache)
CI->>Turbo: check-types (with cache)
CI->>Turbo: build (with cache)
CI->>Tests: run test suite
Tests-->>CI: test results
CI->>CI: pnpm audit
CI->>CI: CodeQL analysis
CI-->>Dev: CI status (pass/fail)
Greptile's behavior is changing!From now on, if a review finishes with no comments, we will not post an additional "statistics" comment to confirm that our review found nothing to comment on. However, you can confirm that we reviewed your changes in the status check section. This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR". |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (34)
.env.example.github/dependabot.yml.github/workflows/ci.yml.github/workflows/release.yml.gitignore.husky/pre-commit.nvmrc.prettierignore.prettierrc.vscode/extensions.json.vscode/settings.jsonREADME.mdapps/.gitkeepdocker-compose.ymleslint.config.jspackage.jsonpackages/eslint-config/base.jspackages/eslint-config/nextjs.jspackages/eslint-config/node.jspackages/eslint-config/package.jsonpackages/shared/eslint.config.jspackages/shared/package.jsonpackages/shared/src/constants.tspackages/shared/src/index.tspackages/shared/src/types.tspackages/shared/src/validators.tspackages/shared/tsconfig.jsonpackages/tsconfig/base.jsonpackages/tsconfig/library.jsonpackages/tsconfig/nextjs.jsonpackages/tsconfig/node.jsonpackages/tsconfig/package.jsonpnpm-workspace.yamlturbo.json
🧰 Additional context used
🧬 Code graph analysis (3)
packages/eslint-config/nextjs.js (1)
packages/eslint-config/base.js (2)
baseConfig(8-77)baseConfig(8-77)
packages/shared/eslint.config.js (1)
packages/eslint-config/base.js (2)
baseConfig(8-77)baseConfig(8-77)
eslint.config.js (1)
packages/eslint-config/base.js (2)
baseConfig(8-77)baseConfig(8-77)
🪛 dotenv-linter (4.0.0)
.env.example
[warning] 10-10: [UnorderedKey] The HOST key should go before the PORT key
(UnorderedKey)
[warning] 21-21: [UnorderedKey] The GITHUB_CALLBACK_URL key should go before the GITHUB_CLIENT_ID key
(UnorderedKey)
[warning] 25-25: [UnorderedKey] The JWT_EXPIRES_IN key should go before the JWT_SECRET key
(UnorderedKey)
🪛 GitHub Actions: CI
packages/shared/src/index.ts
[error] 1-1: ESLint parsing error: Enabling "project" does nothing when "projectService" is enabled. You can remove the "project" setting.
packages/shared/src/constants.ts
[error] 1-1: ESLint parsing error: Enabling "project" does nothing when "projectService" is enabled. You can remove the "project" setting.
packages/shared/src/types.ts
[error] 1-1: ESLint parsing error: Enabling "project" does nothing when "projectService" is enabled. You can remove the "project" setting.
packages/shared/src/validators.ts
[error] 1-1: ESLint parsing error: Enabling "project" does nothing when "projectService" is enabled. You can remove the "project" setting.
🪛 markdownlint-cli2 (0.18.1)
README.md
63-63: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
92-92: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
⏰ 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). (1)
- GitHub Check: Greptile Review
🔇 Additional comments (44)
.prettierrc (1)
1-10: LGTM! Well-configured Prettier settings.The configuration follows standard Prettier best practices:
- Enforces consistent formatting across the monorepo
trailingComma: "es5"provides good ES5 compatibilityendOfLine: "lf"ensures cross-platform consistencyprintWidth: 100balances readability with modern screen widths.husky/pre-commit (1)
1-1: No changes required. Husky v9.1.7 is configured, which supports the simplified pre-commit hook format without shebang. The current code is correct.pnpm-workspace.yaml (1)
1-3: LGTM! Standard pnpm workspace configuration.The workspace configuration follows pnpm best practices with clear separation between applications (
apps/*) and shared packages (packages/*). Thepackages/directory correctly contains shared packages (eslint-config, shared, tsconfig), and the overall structure is properly configured.packages/tsconfig/package.json (1)
1-9: LGTM! Well-structured TypeScript config package.The package manifest follows monorepo best practices with the
privateflag for internal tooling and thefilesarray correctly including all JSON config files..vscode/extensions.json (1)
1-13: LGTM! Comprehensive and relevant extension recommendations.The extension list appropriately covers linting, formatting, TypeScript tooling, database management, testing, containerization, and developer productivity tools that align with the monorepo stack.
.gitignore (1)
1-47: LGTM! Comprehensive and well-organized ignore patterns.The
.gitignoreappropriately covers all necessary artifacts for a monorepo with Turborepo, including dependency directories, build outputs, environment files (with proper.env.exampleexception), IDE configs, and Docker overrides. The organization by category makes it maintainable.turbo.json (2)
1-41: Well-configured Turborepo pipeline with appropriate caching strategies.The configuration correctly sets up task dependencies for topological builds, specifies outputs for caching, disables caching for persistent tasks (
dev,test:watch), and properly declares environment variables. The global dependencies on.envfiles ensure tasks invalidate when environment changes.
15-16: Thecheck-typestask dependency is appropriate for this codebase.The
topodependency is sufficient because thecheck-typesscript runstsc --noEmitto check types against source files, and there are no workspace packages that depend on compiled outputs from other packages. The suggested change to^buildis only necessary if workspace packages import types from other workspace packages' built outputs, which is not the case here..env.example (1)
1-31: LGTM! Well-organized environment template with logical grouping.The environment variables are clearly organized by feature (server, database, authentication, etc.) with appropriate placeholder values and helpful comments. The logical grouping by service is more maintainable than strict alphabetical ordering suggested by the linter warnings.
The
JWT_SECRETplaceholder includes a clear production warning, and all sensitive values are properly marked as examples..github/workflows/ci.yml (3)
1-16: Well-structured CI workflow with proper concurrency handling.The workflow setup is solid with appropriate triggers, concurrency groups to cancel stale runs, and Turborepo remote caching configuration.
23-58: Build job is well-organized with comprehensive checks.The step sequence (format → lint → type check → build → test) follows a logical fail-fast pattern. Using
fetch-depth: 2enables Turbo to properly detect changes for incremental builds.
89-95: No action required —typescriptis a valid CodeQL language identifier.CodeQL officially supports
typescriptas an alias forjavascript-typescript. Using either form works correctly without issues. Whilejavascript-typescriptis the canonical identifier, the alias is fully supported and requires no change.Likely an incorrect or invalid review comment.
docker-compose.yml (2)
24-27: Hardcoded database credentials - acceptable for local dev only.The plaintext credentials are fine for local development. Ensure
.envfile support or secrets management is added before any production deployment.
1-77: Docker Compose configuration is well-structured for local development.Good practices observed:
- Health checks with proper intervals and retries
- Named volumes for data persistence
- Optional tools behind profiles to avoid resource overhead
- Service dependencies with health conditions
packages/shared/package.json (1)
9-26: Well-defined exports map with correct resolution order.The exports configuration properly places
typesbeforeimportfor each subpath, ensuring TypeScript can resolve types correctly in all module resolution modes..vscode/settings.json (1)
1-43: Comprehensive VS Code workspace settings.Well-configured IDE settings that:
- Properly integrate ESLint flat config with monorepo working directories
- Disable
organizeImportsto prevent conflicts with ESLint's import rules- Use workspace TypeScript SDK for consistency
- Exclude build artifacts from search for better performance
.github/workflows/release.yml (1)
14-16: Good concurrency configuration for releases.Setting
cancel-in-progress: falseprevents accidental cancellation of in-flight releases, which is the correct behavior for release workflows..github/dependabot.yml (2)
11-20: Good dependency grouping strategy with conservative production updates.Limiting production dependencies to
patchupdates while allowingminorfor dev dependencies is a sensible approach that balances security updates with stability.
1-47: Well-configured Dependabot for multi-ecosystem monorepo.Covers npm, GitHub Actions, and Docker with appropriate schedules and labeling. The commit message prefixes will help with changelog generation.
package.json (2)
10-22: Well-organized script definitions leveraging Turbo.The scripts properly delegate to Turbo for parallelizable tasks while keeping format commands at the root level where they make sense. The
cleanscript correctly removes both Turbo cache and node_modules.
34-42: Correct lint-staged configuration.Running ESLint before Prettier ensures that auto-fixed code is also properly formatted. The file pattern coverage is appropriate for the project structure.
packages/eslint-config/base.js (4)
1-6: LGTM! Clean import structure.The imports follow a logical order and use the correct ESM syntax for ESLint v9 flat config.
27-63: LGTM! Well-configured rule set.The TypeScript and import rules are well-balanced:
- Unused variable patterns allow intentional ignores with
_prefix- Type imports enforce consistency with inline syntax
- Import ordering is comprehensive and alphabetized
- Pragmatic disabling of explicit return types for better DX
65-77: LGTM! Comprehensive ignore patterns.The ignore patterns appropriately exclude build artifacts, dependencies, and framework-specific cache directories.
19-22: Node.js version requirement is already documented. The monorepo'spackage.jsonspecifiesengines.node: >=22.0.0and.nvmrcenforces Node.js 22, both of which satisfy the requirement forimport.meta.dirname(Node.js ≥20.11.0 or ≥21.2.0). No action needed.packages/eslint-config/node.js (1)
1-14: LGTM! Clean Node.js-specific config extension.The configuration appropriately extends the base config with the
no-process-exitrule, which enforces proper error handling in Node.js environments by discouraging abrupt process termination.packages/eslint-config/nextjs.js (1)
1-25: LGTM! Well-structured Next.js ESLint configuration.The configuration properly:
- Extends the base config with Next.js-specific concerns
- Adds both browser and node globals (appropriate for Next.js SSR/SSG)
- Registers the Next.js plugin following ESLint v9 flat config conventions
- Applies both
recommendedandcore-web-vitalsrule sets for comprehensive Next.js best practicespackages/eslint-config/package.json (1)
15-29: Dependency versions verified—no compatibility or security issues found.All specified versions are compatible: @typescript-eslint@8.21.0 satisfies the eslint "^9.0.0" peer requirement, typescript "^5.7.0" is within the ">=4.8.4 <5.8.0" constraint, and @next/eslint-plugin-next@15.1.3 is confirmed compatible with ESLint 9 (added in Next.js 15). No public CVEs or security advisories exist for any of the pinned package versions.
packages/shared/src/constants.ts (1)
16-86: LGTM: Well-structured configuration constants.The remaining constants are well-designed:
- WebSocket reconnection uses standard exponential backoff with sensible limits
- Redis key factories maintain consistent naming conventions
- Blacklist patterns appropriately cover sensitive files
- Tier features demonstrate proper progressive enhancement across subscription levels
- Rate limits are reasonable and tiered appropriately
- Proper use of
as constfor type safety and literal preservationpackages/shared/tsconfig.json (1)
1-9: LGTM: Standard library TypeScript configuration.The configuration correctly extends the library base config and sets appropriate paths for a shared library package. The include/exclude patterns are standard and correct.
packages/tsconfig/base.json (1)
1-38: Overall: Excellent type safety foundation.The base TypeScript configuration provides a solid foundation with modern best practices, strict type checking, and proper module resolution. The comprehensive strict mode flags will catch many potential bugs at compile time.
packages/tsconfig/nextjs.json (1)
1-19: LGTM! Next.js configuration is well-structured.The TypeScript configuration appropriately extends the base config and includes Next.js-specific settings like the bundler module resolution, JSX preservation, and the Next.js plugin.
packages/tsconfig/node.json (1)
1-13: LGTM! Node.js configuration follows best practices.The TypeScript configuration correctly uses NodeNext for both module and moduleResolution, which is the recommended approach for modern Node.js projects with ESM support.
packages/tsconfig/library.json (1)
1-14: LGTM! Library configuration appropriately enables project references.The
composite: truesetting is essential for TypeScript project references, enabling efficient incremental builds across the monorepo. The rest of the configuration follows Node.js best practices.packages/shared/src/validators.ts (4)
1-29: LGTM! Enum schemas are well-defined.The enum schemas cover appropriate domain values for user status, subscription tiers, roles, and WebSocket message types. The validation constraints are clear and type-safe.
Note: The pipeline failure is due to the ESLint configuration issue flagged in
packages/shared/src/index.ts.
31-51: LGTM! Activity and status schemas have appropriate validation.The activity payload schema includes sensible constraints (e.g., 255-char paths, 0-100 intensity range), and the user status schema properly composes the status type with optional activity data.
53-77: LGTM! Message and authentication schemas are well-designed.The WebSocket message schema appropriately uses
z.unknown()for flexible payload typing, the poke message has a sensible character limit, and the login schema includes a helpful error message for the GitHub OAuth flow.
79-102: LGTM! User update and pagination schemas follow best practices.The schemas appropriately support partial updates, use
z.coercefor query parameter type conversion, and include sensible defaults and constraints. The exported TypeScript types maintain type safety across runtime validation and compile-time checking.packages/shared/src/index.ts (1)
1-3: No action needed. This issue has already been resolved.The ESLint configuration no longer contains the conflicting
projectsetting. The current setup inpackages/eslint-config/base.jsonly usesprojectService: true, which is the correct configuration. This was fixed in commit d49c904.The barrel export pattern in
packages/shared/src/index.tsis appropriate and correct.Likely an incorrect or invalid review comment.
packages/shared/src/types.ts (5)
1-26: LGTM! Well-defined type aliases.The string literal unions are appropriate for their domains (user presence, subscription tiers, roles, and WebSocket message types) and provide good type safety.
81-97: LGTM! Well-structured payload interfaces.Both
PokePayloadandConflictAlertPayloadare appropriately typed for their respective features (user interactions and merge conflict detection).
99-119: LGTM! Standard utility types.Both
ApiErrorandPaginatedResponse<T>follow common API patterns and provide all necessary fields for error handling and pagination.
1-1: Note: Pipeline failure is unrelated to this file.The ESLint parsing error in the CI pipeline is a configuration issue in your ESLint setup, not a problem with this types file. You'll need to remove the
projectsetting from your ESLint configuration sinceprojectServiceis already enabled.
67-79: Verify timestamp type consistency and GitHub ID type.Two observations about the UserDTO interface:
Timestamp type inconsistency:
createdAtis typed asstringwhileUserStatus.updatedAtisnumber. Confirm whether this intentional difference (e.g., ISO 8601 strings for persistence vs Unix timestamps for real-time updates) or an inconsistency that should be addressed.GitHub ID type:
githubIdis typed asstring. Verify this matches how your GitHub OAuth integration handles GitHub user IDs and how they're stored in your database.
- Fix release workflow to use inputs.version for manual dispatch - Pin Node.js version to 22.12.0 in .nvmrc - Expand .prettierignore with common patterns - Rename apps/.gitkeep to apps/README.md for visibility - Remove duplicate ESLint ignores from root config - Align engines.pnpm with packageManager version - Add placeholder test script to shared package - Add EpochMillis and Intensity types with JSDoc - Add language specifiers to README code blocks
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
.github/workflows/release.yml.nvmrc.prettierignoreREADME.mdapps/README.mdeslint.config.jspackage.jsonpackages/shared/package.jsonpackages/shared/src/types.ts
🔇 Additional comments (14)
README.md (2)
63-63: ✅ Language specifiers added to code blocks — Previous feedback addressed.Both fenced code blocks now include the
textlanguage specifier, resolving the markdown linting violations flagged in prior reviews.Also applies to: 92-92
1-170: ✅ Comprehensive and well-structured documentation.The README effectively communicates the project's purpose, provides clear onboarding instructions, documents the architecture and tech stack, lists development commands, and specifies environment configuration requirements. All sections are logically organized and appropriately detailed for both new contributors and experienced developers.
apps/README.md (1)
1-9: ✅ File rename from.gitkeeptoREADME.md— Previous suggestion implemented.The directory now has discoverable documentation that will be visible in GitHub web interface and documentation tools. The content appropriately documents the planned applications and phases.
.prettierignore (1)
1-38: ✅ Comprehensive ignore patterns appropriately expanded.The file now covers all essential categories: build outputs, lock files, environment files, IDE/editor files, OS-specific files, and logs. This expansion ensures that Prettier skips files that should not be auto-formatted, which is especially important in a monorepo where developers may use different editors and configurations.
eslint.config.js (1)
1-10: LGTM! Previous feedback addressed.The redundant ignore patterns have been removed, and the configuration now only includes root-specific ignores (
packages/**,apps/**). This is clean and appropriate for a monorepo root where individual packages have their own ESLint configurations..github/workflows/release.yml (2)
7-12: LGTM! Previous feedback addressed.The
workflow_dispatchinput is now properly utilized. The workflow setsRELEASE_VERSIONfrom the input (line 22), adjusts the release condition to allow manual triggers (line 69), and uses the input to construct the tag name (line 71). This enables manual releases as intended.
67-72: Release step correctly implements manual dispatch support.The implementation correctly handles both trigger types:
- Manual dispatch: Uses
inputs.version(e.g., "1.0.0") and formats it with the 'v' prefix to create "v1.0.0"- Tag push: Uses
github.ref_namedirectly, which already includes the 'v' prefixThis addresses the previous feedback and should work as expected.
.nvmrc (1)
1-1: LGTM! Previous feedback addressed.The Node.js version is now pinned to the full patch version
22.12.0, providing strict reproducibility across development environments and CI/CD pipelines. This addresses the previous recommendation.packages/shared/package.json (1)
30-37: LGTM! Previous feedback addressed.The test script placeholder has been added (line 35), making the package explicitly testable by CI/CD pipelines. This allows Turbo and CI workflows to recognize the package as having a test interface, even though tests aren't implemented yet.
package.json (1)
5-9: LGTM! Previous feedback addressed.The pnpm engine constraint is now aligned with the
packageManagerfield. Theengines.pnpmvalue of>=10.27.0matches the pinned version10.27.0, preventing unexpected behavior across different pnpm versions while maintaining forward compatibility.packages/shared/src/types.ts (4)
1-26: LGTM! Well-defined type literals.The string literal union types are clearly documented and cover the expected use cases for user presence, subscription tiers, team roles, and WebSocket messaging.
28-39: Excellent improvements from past feedback!The addition of
EpochMillistype alias and the brandedIntensitytype successfully addresses the previous review concerns:
- Timestamps now have explicit units documented
- Intensity constraints are visible at the type level
Note that branded types provide compile-time safety but don't enforce runtime constraints—ensure your validator schemas in
validators.tsperform actual range checks for intensity values.
41-84: LGTM! Consistent use of type aliases.The interfaces correctly incorporate the
IntensityandEpochMillistype aliases with clear documentation. The optional fields are appropriately marked, and theWebSocketMessage<T>generic envelope pattern is well-designed.
100-107: LGTM! Clean payload and response interfaces.The
PokePayload,ApiError, andPaginatedResponse<T>interfaces are well-structured with appropriate optional fields and clear semantics. The genericPaginatedResponse<T>pattern provides good reusability.Also applies to: 118-138
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
packages/shared/src/constants.ts
🔇 Additional comments (1)
packages/shared/src/constants.ts (1)
1-10: LGTM! TTL timing concern has been addressed.The 60-second TTL (2× the 30-second heartbeat interval) now provides adequate tolerance for a single missed heartbeat. The comment clearly documents this intentional relationship.
1 participant
Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.