chore: node and libs update#74
Conversation
WalkthroughNode.js was bumped to 22.18.0 across CI, Docker base images, and package.json engines; the pnpm workspace also had multiple dependency minor/patch bumps and the removal of Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub. |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
package.json (1)
12-12: Optional: enforce the Node version locally via toolfile.
Consider adding/updating a .nvmrc (or .tool-versions/Volta) to 22.18.0 so contributors automatically use the correct Node locally.Would you like me to add a minimal .nvmrc update in this PR?
docker/web-parser/Dockerfile (1)
1-1: Optional: pin base image by digest to avoid tag drift.
To make builds fully reproducible, consider pinning the image with a sha256 digest (or use a centralized build arg/version management).If you want, I can open a follow-up to add digest pinning or a shared ARG strategy across Dockerfiles.
.github/workflows/ci.yml (1)
37-41: Optional: make version resolution more robust.
You can add check-latest to ensure the exact patch is fetched, and/or reference a toolfile if you introduce .nvmrc.Apply this small tweak:
- name: Node uses: actions/setup-node@v4 with: - node-version: 22.18.0 + node-version: 22.18.0 + check-latest: true cache: 'pnpm'docker/web-storefront/Dockerfile (1)
1-1: Optional: centralize Node version across Dockerfiles.
To simplify future bumps, consider using a shared build arg (or a buildx bake file) so you only change the version once.I can draft a bake.hcl or a small Makefile/CI matrix to centralize and validate all images together.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
.github/workflows/ci.yml(1 hunks)docker/web-app/Dockerfile(1 hunks)docker/web-parser/Dockerfile(1 hunks)docker/web-storefront/Dockerfile(1 hunks)package.json(1 hunks)
⏰ 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: build
🔇 Additional comments (7)
package.json (2)
12-12: Engines bump to Node >=22.18.0 looks good and aligns with CI/Docker.
This keeps local dev aligned with runtime images and CI.
12-12: No stale Node version references found
All Node version tags have been updated to22.18.0and no older versions remain:
- docker/web-app/Dockerfile →
node:22.18.0-alpine- docker/web-parser/Dockerfile →
node:22.18.0-slim- docker/web-storefront/Dockerfile →
node:22.18.0-alpine- .github/workflows/ci.yml →
node-version: 22.18.0- package.json →
"engines".node: ">=22.18.0"No references to
22.17.*or other hard-coded Node tags were found in README or compose files.docker/web-parser/Dockerfile (1)
1-1: Docker base bumped to node:22.18.0-slim — aligned with CI and engines.
Slim is a good choice here given Playwright deps are installed explicitly..github/workflows/ci.yml (2)
40-41: CI now uses Node 22.18.0 — good alignment.
Matches engines and Docker images.
3-19: Heads-up: Dockerfile-only changes won’t trigger this CI.
paths-ignore excludes docker/** for both push and PR events. If you intend CI to run when Dockerfiles change, you’ll need to adjust these filters or add a dedicated workflow for image builds.Do you want CI to run when only Dockerfiles are updated? I can propose a minimal workflow to lint/build images on Dockerfile changes.
docker/web-storefront/Dockerfile (1)
1-1: Docker base bumped to node:22.18.0-alpine — consistent with the stack.
No other changes; build and runtime should remain identical.docker/web-app/Dockerfile (1)
1-1: Docker base bumped to node:22.18.0-alpine — aligned with engines and CI.
Looks good.
| @@ -1,4 +1,4 @@ | |||
| FROM node:22.17.1-slim AS base | |||
| FROM node:22.18.0-slim AS base | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Sanity check that the tag exists on Docker Hub.
If 22.18.0-slim isn’t published yet, builds will fail.
🌐 Web query:
Does the official Docker Hub "node" image provide tags "22.18.0-slim" and "22.18.0-alpine"?
💡 Result:
The official Docker Hub "node" image does not provide tags exactly named "22.18.0-slim" or "22.18.0-alpine", based on the most recent publicly available tags.
- The closest available "slim" tag is "22.18.0-bullseye-slim"[6]. The tag naming convention follows the pattern:
node:<version>-<deb-based-release>-slim(e.g.,node:22.18.0-bullseye-slim). - For the Alpine variant, the available tags are in the form "22.18-alpine3.22" or "22.18-alpine3.21". There is no tag with the full patch version (
22.18.0) together with thealpinevariant (e.g.,node:22.18-alpine3.22exists, but notnode:22.18.0-alpine) [8].
Summary Table:
| Tag | Officially Available? |
|---|---|
| node:22.18.0-slim | No |
| node:22.18.0-bullseye-slim | Yes [6] |
| node:22.18.0-alpine | No |
| node:22.18-alpine3.22 | Yes [8] |
| node:22.18-alpine3.21 | Yes [8] |
- No exact tag named
node:22.18.0-slimornode:22.18.0-alpine. - Use
node:22.18.0-bullseye-slimfor the "slim" variant andnode:22.18-alpine3.22(or.21) for the Alpine-based variant[6][8].
If you need to match tags exactly for automation or image pulls, use the exact forms above for correct results.
Citations:
- 1: https://docs.docker.com/reference/cli/docker/image/tag/
- 2: https://hub.docker.com/r/s390x/node/tags
- 3: https://labs.iximiuz.com/tutorials/how-to-choose-nodejs-container-image
- 4: https://hub.docker.com/r/arm32v7/node/tags
- 5: https://github.com/nodejs/docker-node
- 6: https://hub.docker.com/_/node/tags?page=1&name=slim
- 7: https://hub.docker.com/search?badges=official
- 8: https://hub.docker.com/_/node/tags?page=1&name=18-alpine
- 9: https://hub.docker.com/search?q=node
- 10: https://hub.docker.com/r/nikolaik/python-nodejs
Incorrect Docker image tag – update to an existing tag
The tag node:22.18.0-slim does not exist on Docker Hub and will cause CI/build failures. Please update to a valid, published tag.
• File: docker/web-parser/Dockerfile, Line 1
• Replace with the “bullseye-slim” variant or, if you need Alpine, with an alpine3.x tag.
Suggested diff:
-FROM node:22.18.0-slim AS base
+FROM node:22.18.0-bullseye-slim AS baseAlternative Alpine variants (if desired):
node:22.18-alpine3.22
node:22.18-alpine3.21
🤖 Prompt for AI Agents
In docker/web-parser/Dockerfile at line 1, the base image tag
"node:22.18.0-slim" does not exist and causes build failures; update the FROM
line to a valid tag such as "node:22.18-bullseye-slim" (or use an Alpine variant
like "node:22.18-alpine3.22" or "node:22.18-alpine3.21") so the Dockerfile uses
a published Node image.
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
pnpm-workspace.yaml (1)
5-72: Ensure PNPM’s catalog feature is enabled and actually used
- The root
package.jsonspecifiespackageManager: "pnpm@10.14.0", so catalog support (v9+) is available.- No CI workflows (e.g. under
.github/workflows/) reference pnpm or Corepack—please verify your CI setup runs Corepack (oractions/setup-nodewithcorepack: true) so that pnpm@10.14.0 is used in CI.- We found no occurrences of the
catalog:protocol in anypackage.json, so thecatalogblock inpnpm-workspace.yamlisn’t being applied.Mandatory refactor: update your dependency declarations to use the
catalog:protocol. For example, in eachpackage.json:- "@antfu/eslint-config": "^5.2.1" + "@antfu/eslint-config": "catalog:@antfu/eslint-config"
🧹 Nitpick comments (2)
pnpm-workspace.yaml (2)
51-51: Avoid ‘latest’ in catalog to keep builds deterministic
nitropack: latestmakes builds non-reproducible. Prefer a caret or exact version aligned with your lockfile and CI to reduce surprise upgrades.If you want, I can scan the repo and propose a conservative pinned range based on the lockfile.
27-27: Align @types/node with your Node 22 runtimeI ran a scan across all
package.jsonfiles and found no other@types/nodedeclarations—this override inpnpm-workspace.yamlis the only one. To avoid picking up Node 24-only APIs, update it to match your Node 22.18.0 runtime:pnpm-workspace.yaml … - '@types/node': ^24.3.0 + '@types/node': ^22.18.0
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
pnpm-workspace.yaml(3 hunks)
⏰ 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: build
🔇 Additional comments (5)
pnpm-workspace.yaml (5)
5-72: Catalog bumps look coherent and consistent with the Node 22.18.0 updateMinor/patch upgrades across Nuxt, VueUse, Vite, ESLint, OpenAI, Unovis, etc. are generally safe, and the versions are internally consistent (e.g., all VueUse entries at 13.7.0). No red flags in the catalog itself.
5-72: 'unbuild' removal verified
- Only occurrences are in
pnpm-lock.yaml(lockfile artifacts)- No build scripts, config files, or CI workflows reference
unbuildRemoval is complete.
5-72: Sanity check passed: engines.node and lockfile are in order
- Verified
package.jsonat workspace root declaresengines.node: >=22.18.0- Confirmed presence of
pnpm-lock.yamlNo further action required.
57-57: No deprecated OpenAI API usage found
A search through your code shows only standard instantiation ofnew OpenAI({…}), use ofOpenAIChatCompletionsModel, and the agents’Agent/runflow—no streaming flags, noresponse_format, and no other deprecated calls. The bump toopenai@^5.12.2can proceed.
67-67: Confirm Vite override aligns with Nuxt’s Vite requirementOur scan shows:
- pnpm-workspace.yaml (lines 60–80) pins
vite: ^7.1.2- The only explicit
viteentry across your packages is viacatalog:vitein the root workspace.- Nuxt is also consumed via
catalog:nuxtin these packages:
- @roll-stack/geo-vault
- @roll-stack/web-app
- @roll-stack/web-storefront
- @roll-stack/ui
Please verify that the Nuxt version provided by your catalog accepts Vite ^7.1.2 (e.g. run
npm view nuxt@<your-catalog-version> peerDependencies.viteor inspect its internal dependency).
If Nuxt’s own Vite requirement is lower or mismatched, remove or adjust this override. If you intentionally need Vite 7.x across your workspace, confirm no plugins break.
1 participant
Summary by CodeRabbit