Add markdown#24
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughNode.js runtime is bumped from 22.17.0 to 24.17.0 across ChangesNode 24 and tsdown toolchain update
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
packages/schemas/tsconfig.json (1)
3-3: 💤 Low valueConsider updating target to a newer ES version.
The
targetis set toES2020, but Node.js 24.17.0 supports ES2022+ features. Unless there's a specific reason to maintain ES2020 compatibility, consider updating toES2022or newer for access to modern JavaScript features.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/schemas/tsconfig.json` at line 3, The target compiler option in the tsconfig.json file is set to ES2020, but since Node.js 24.17.0 supports ES2022 and newer features, update the target value from ES2020 to ES2022 to allow access to modern JavaScript features and better align with the runtime capabilities.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/server/tsconfig.json`:
- Around line 13-15: The TypeScript path alias for `@repo/schemas` has been
removed from the tsconfig.json file, so the server app now relies on resolving
`@repo/schemas` as an npm package import. To make the imports of CVParsedSchema,
JobParsedSchema, CVParsed, JobParsed, and ALLOWED_SENIORITY work across the 15
files in the server app that depend on `@repo/schemas`, you need to build the
packages/schemas package by running npm run build (or the appropriate build
command) in the packages/schemas directory to generate the dist directory that
these imports require.
In `@apps/server/tsdown.config.ts`:
- Line 7: The tsdown target configuration is set to 'node22' but the .nvmrc file
specifies Node.js runtime version 24.17.0, causing a mismatch between the build
target and runtime. Update the target property in tsdown.config.ts from 'node22'
to 'node24' to align the build target with the runtime version specified in
.nvmrc.
In `@packages/schemas/package.json`:
- Around line 5-17: The tsdown configuration currently uses `dts: true` which
does not generate the `.d.mts` and `.d.cts` declaration files that are
referenced in the package.json exports field. Locate the tsdown configuration in
the build setup and update the `dts` option from `dts: true` to `dts: {
cjsReexport: true }` to ensure the correct declaration file extensions are
emitted for the dual ESM/CJS package structure.
In `@packages/schemas/tsdown.config.ts`:
- Line 9: The tsdown target property in tsdown.config.ts is set to 'node22', but
.nvmrc specifies Node.js version 24.17.0, creating a mismatch between the build
target and the actual runtime version. Update the target property value from
'node22' to 'node24' to align the build configuration with the Node.js runtime
version specified in .nvmrc.
---
Nitpick comments:
In `@packages/schemas/tsconfig.json`:
- Line 3: The target compiler option in the tsconfig.json file is set to ES2020,
but since Node.js 24.17.0 supports ES2022 and newer features, update the target
value from ES2020 to ES2022 to allow access to modern JavaScript features and
better align with the runtime capabilities.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: f59508cd-30fd-49ca-978d-e80fef18ecde
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!**/pnpm-lock.yaml
📒 Files selected for processing (12)
.github/workflows/ci.yml.github/workflows/codeql.yml.nvmrcapps/server/package.jsonapps/server/tsconfig.eslint.jsonapps/server/tsconfig.jsonapps/server/tsdown.config.tseslint.config.tspackage.jsonpackages/schemas/package.jsonpackages/schemas/tsconfig.jsonpackages/schemas/tsdown.config.ts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4fea3ecc90
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/server/Dockerfile (1)
19-23:⚠️ Potential issue | 🟠 Major | ⚡ Quick winRun the server container as a non-root user.
At Line 23, the process starts without any
USERdirective, so it runs as root by default. This weakens container isolation and violates baseline container hardening.🔧 Suggested fix
WORKDIR /app/apps/server EXPOSE 5005 +USER node CMD ["pnpm", "start"]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/server/Dockerfile` around lines 19 - 23, The Dockerfile runs the container process as root because there is no USER directive specified before the CMD instruction. Add a USER directive before the CMD ["pnpm", "start"] statement to specify a non-root user account for running the server process. If the user does not already exist in the base image, create it earlier in the Dockerfile using appropriate commands (such as RUN addgroup and RUN adduser or similar depending on the base image).Source: Linters/SAST tools
apps/client/Dockerfile (1)
1-20:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd a non-root USER to harden the container security posture.
The Docker image currently runs as the default root user. This is a security risk in production deployments, as any compromise could grant full system access. Create a dedicated non-root user for running the application.
🔒 Proposed fix to add a non-root user
FROM node:24-alpine AS builder WORKDIR /app RUN corepack enable && corepack prepare pnpm@latest --activate # workspace files COPY package.json pnpm-lock.yaml pnpm-workspace.yaml ./ # IMPORTANT: include full workspace (recommended) COPY . . # install all workspace dependencies RUN pnpm install --frozen-lockfile # build client and its workspace dependencies (e.g. `@repo/schemas`) in order RUN pnpm --filter client... build # production stage +FROM node:24-alpine +RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001 +WORKDIR /app +COPY --from=builder --chown=nextjs:nodejs /app/apps/client/.next ./ +COPY --from=builder --chown=nextjs:nodejs /app/node_modules ./node_modules +USER nextjs +EXPOSE 3000 +CMD ["node", "server.js"]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/client/Dockerfile` around lines 1 - 20, The Dockerfile is missing a USER instruction to run the container as a non-root user, which is a security risk. After the production stage label, add a RUN instruction to create a dedicated non-root user (or use the existing 'node' user from the base image), then add a USER instruction to switch to that user before the final CMD or ENTRYPOINT. This ensures the application runs with minimal privileges, limiting the impact of potential security breaches.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/server/package.json`:
- Line 8: Update the documentation in apps/server/README.MD to reflect the
change in the start script. Find the section that describes what the pnpm start
command does (currently referencing dist/server.js) and update it to correctly
state that it runs dist/server.mjs instead, ensuring the documentation is
consistent with the updated start script in package.json that now points to
dist/server.mjs.
---
Outside diff comments:
In `@apps/client/Dockerfile`:
- Around line 1-20: The Dockerfile is missing a USER instruction to run the
container as a non-root user, which is a security risk. After the production
stage label, add a RUN instruction to create a dedicated non-root user (or use
the existing 'node' user from the base image), then add a USER instruction to
switch to that user before the final CMD or ENTRYPOINT. This ensures the
application runs with minimal privileges, limiting the impact of potential
security breaches.
In `@apps/server/Dockerfile`:
- Around line 19-23: The Dockerfile runs the container process as root because
there is no USER directive specified before the CMD instruction. Add a USER
directive before the CMD ["pnpm", "start"] statement to specify a non-root user
account for running the server process. If the user does not already exist in
the base image, create it earlier in the Dockerfile using appropriate commands
(such as RUN addgroup and RUN adduser or similar depending on the base image).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 8042701d-e6c1-4849-a204-f3a7ce5bc02e
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!**/pnpm-lock.yaml
📒 Files selected for processing (7)
apps/client/Dockerfileapps/server/Dockerfileapps/server/package.jsonapps/server/tsdown.config.tspackages/schemas/package.jsonpackages/schemas/tsconfig.jsonpackages/schemas/tsdown.config.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/schemas/tsdown.config.ts
- apps/server/tsdown.config.ts
- packages/schemas/tsconfig.json
- packages/schemas/package.json
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/client/Dockerfile`:
- Around line 30-32: The Dockerfile sets USER to nginx (non-root) but attempts
to expose privileged port 80, which requires root permissions to bind. The nginx
process running as non-root cannot bind to port 80, causing startup failure.
Either remove the USER nginx directive to keep the container running as root for
the master process, or change the EXPOSE and nginx configuration to use an
unprivileged port like 8080 and update the corresponding port mapping in the
docker-compose configuration to expose 8080 instead of 80.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: aed71eb5-7e6f-45c6-a0d8-c8c7b608dc6c
📒 Files selected for processing (2)
apps/client/Dockerfileapps/server/Dockerfile
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/server/Dockerfile
Summary by CodeRabbit