chore: lib updates#253
Conversation
WalkthroughThe PR updates Node.js Docker base images from version 22 to version 24 across multiple services, refactors Tailwind CSS utility class syntax from prefixed to suffixed important modifiers in Vue components, updates package manager and Node.js engine version requirements, adjusts PostgreSQL volume mount paths in docker-compose files, and updates workspace dependencies. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes The changes are largely repetitive and mechanical: consistent Docker base image version bumps across seven files following the same pattern, standardized Tailwind CSS modifier refactoring across four components, and straightforward dependency version updates.
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 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 |
|
|
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: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (15)
apps/atrium-telegram/app/components/ticket/Card.vue(1 hunks)apps/web-app/app/components/PartnerAgreementCard.vue(2 hunks)apps/web-app/app/components/chart/KitchenChecks.client.vue(1 hunks)apps/web-app/app/components/chart/KitchenRevenue.client.vue(1 hunks)docker/atrium-telegram/Dockerfile(1 hunks)docker/core-telegram/Dockerfile(1 hunks)docker/storefront-telegram/Dockerfile(1 hunks)docker/web-app/Dockerfile(1 hunks)docker/web-app/docker-compose.yaml(1 hunks)docker/web-parser/Dockerfile(1 hunks)docker/web-storefront/Dockerfile(1 hunks)docker/web-storefront/docker-compose.yaml(1 hunks)docker/webinar/Dockerfile(1 hunks)package.json(1 hunks)pnpm-workspace.yaml(3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-01T10:34:55.317Z
Learnt from: hmbanan666
PR: nextorders/roll-stack#40
File: package.json:5-6
Timestamp: 2025-08-01T10:34:55.317Z
Learning: The latest version of pnpm on npm registry is 10.14.0 as of August 2025, so "npm install -g pnpm" installs this version without needing explicit version specification.
Applied to files:
package.json
⏰ 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 (13)
apps/web-app/app/components/chart/KitchenRevenue.client.vue (1)
2-2: LGTM - consistent important modifier syntax refactor.The change from prefixed (
!px-0) to suffixed (px-0!) important modifier syntax is valid in Tailwind CSS v3.1+. This aligns with the broader refactoring effort across the codebase for consistent utility class formatting.apps/web-app/app/components/PartnerAgreementCard.vue (1)
21-21: LGTM - consistent important modifier syntax refactor.Both changes correctly migrate from prefixed to suffixed important modifier syntax (
!bg-error→bg-error!and!p-4 !ring-accented→p-4! ring-accented!). This maintains consistency with the utility class formatting updates across the codebase.Also applies to: 72-72
apps/web-app/app/components/chart/KitchenChecks.client.vue (1)
2-2: LGTM - consistent important modifier syntax refactor.The refactor from prefixed to suffixed important modifier syntax is correctly applied and consistent with the changes in KitchenRevenue.client.vue and other components.
docker/core-telegram/Dockerfile (1)
1-1: Verify Node.js 24 compatibility across the codebase.The base image is being upgraded from Node 22 to Node 24—a significant major version bump. While the Dockerfile change itself is straightforward, ensure that all workspace dependencies and the Node engine constraint in
package.jsonhave been updated accordingly to support this version.Can you confirm that:
- The
enginesfield inpackage.jsonhas been updated to require Node ≥ 24.11.0?- All dependencies in
pnpm-lock.yamlare compatible with Node 24?- There are no breaking changes in Node 24 that affect your applications?
docker/storefront-telegram/Dockerfile (1)
1-1: Base image upgrade to Node 24.Consistent with other Dockerfiles in the PR. Ensure Node 24 compatibility is verified across the entire workspace (see comment on
docker/core-telegram/Dockerfile).docker/web-app/Dockerfile (1)
1-1: Base image upgrade to Node 24.Consistent with other Dockerfile updates in the PR. Verify Node 24 compatibility as noted in
docker/core-telegram/Dockerfile.docker/webinar/Dockerfile (1)
1-1: Base image upgrade to Node 24.Consistent with other Dockerfile updates in the PR. Verify Node 24 compatibility as noted in
docker/core-telegram/Dockerfile.docker/web-parser/Dockerfile (1)
1-1: Base image upgrade to Node 24.The slim variant is appropriate for this service. Verify Node 24 compatibility as noted in
docker/core-telegram/Dockerfile.docker/web-storefront/Dockerfile (1)
1-1: Base image upgrade to Node 24.Consistent with other Dockerfile updates in the PR. Verify Node 24 compatibility as noted in
docker/core-telegram/Dockerfile.docker/atrium-telegram/Dockerfile (1)
1-1: Base image upgrade to Node 24.Consistent with other Dockerfile updates in the PR. Verify Node 24 compatibility as noted in
docker/core-telegram/Dockerfile.pnpm-workspace.yaml (1)
63-67: Vitest family updates look good.The updates to @vitest/browser-playwright, @vitest/coverage-v8, vitest, and vitest-browser-vue are all patch/minor version bumps, which are generally safe. These align with the Node 24 engine requirement.
package.json (2)
5-5: pnpm version update looks good.The packageManager field update from 10.19.0 to 10.20.0 is a reasonable patch bump that aligns with the package ecosystem updates in pnpm-workspace.yaml.
12-13: Verify Node 24 compatibility by running tests locally.The Node.js engine constraint is bumped from >=22.18.0 to >=24.11.0. While Vite and Vitest both officially support Node 24.11.0, confirm that all devDependencies (especially native modules like Playwright and any ESLint plugins) function correctly under Node 24 by running your test suite and linting pipeline locally. This is a significant version jump and should be validated before merging.
| </h3> | ||
|
|
||
| <div class="w-full text-base/5 font-normal whitespace-pre-wrap break-words line-clamp-5"> | ||
| <div class="w-full text-base/5 font-normal whitespace-pre-wrap wrap-break-word line-clamp-5"> |
There was a problem hiding this comment.
Invalid CSS class name - likely a typo.
The class name wrap-break-word is not a standard Tailwind CSS utility. The original class break-words was correct. This change will cause the word-breaking style to fail, potentially breaking the layout for long words in ticket descriptions.
Apply this diff to restore the correct class:
- <div class="w-full text-base/5 font-normal whitespace-pre-wrap wrap-break-word line-clamp-5">
+ <div class="w-full text-base/5 font-normal whitespace-pre-wrap break-words line-clamp-5">📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <div class="w-full text-base/5 font-normal whitespace-pre-wrap wrap-break-word line-clamp-5"> | |
| <div class="w-full text-base/5 font-normal whitespace-pre-wrap break-words line-clamp-5"> |
🤖 Prompt for AI Agents
In apps/atrium-telegram/app/components/ticket/Card.vue around line 22, the class
name `wrap-break-word` is invalid (typo) and prevents proper word breaking;
replace it with the correct Tailwind utility `break-words` so long words wrap as
intended and restore the original layout behavior.
| - 5433:5432 | ||
| volumes: | ||
| - sushi_atrium_data:/var/lib/postgresql/data | ||
| - sushi_atrium_data:/var/lib/postgresql |
There was a problem hiding this comment.
🧩 Analysis chain
Verify PostgreSQL volume mount path change won't break data persistence.
The change from /var/lib/postgresql/data to /var/lib/postgresql is atypical. PostgreSQL expects data to be stored in a data subdirectory by default. This change could break database initialization or cause data loss if existing volumes contain data in the data subdirectory.
Confirm this change is intentional and that database initialization and persistence work correctly with the new path.
I'll verify this concern by examining the docker-compose files and checking PostgreSQL's expected behavior with volume mounts.
🏁 Script executed:
#!/bin/bash
# Check both docker-compose.yaml files mentioned in the review
echo "=== docker/web-app/docker-compose.yaml (around line 7) ==="
fd 'docker-compose.yaml' --path '*web-app*' -x cat {}
echo ""
echo "=== docker/web-storefront/docker-compose.yaml ==="
fd 'docker-compose.yaml' --path '*web-storefront*' -x cat {}Length of output: 541
🌐 Web query:
PostgreSQL volume mount /var/lib/postgresql vs /var/lib/postgresql/data Docker
💡 Result:
Short answer
Mount the exact data directory (/var/lib/postgresql/data). The official postgres image declares VOLUME /var/lib/postgresql/data, so if you mount the parent (/var/lib/postgresql) Docker can create an anonymous volume for the data subdirectory and your host bind mount will not persist the DB files. Use -v hostpath:/var/lib/postgresql/data (or a named volume) — or explicitly set PGDATA to another path and mount that instead. [1][2][3]
Quick references
- Official usage: mount /var/lib/postgresql/data (example compose). [1]
- Explanation of anonymous-volume / parent-mount behavior and why parent mounts lose the actual data volume. [2]
- Real-world report and workaround (set PGDATA or mount the exact subpath). [3]
---
🏁 Script executed:
```shell
#!/bin/bash
# Retrieve docker-compose files with correct syntax
echo "=== docker/web-app/docker-compose.yaml ==="
cat docker/web-app/docker-compose.yaml 2>/dev/null || echo "File not found"
echo ""
echo "=== docker/web-storefront/docker-compose.yaml ==="
cat docker/web-storefront/docker-compose.yaml 2>/dev/null || echo "File not found"
echo ""
echo "=== Searching for docker-compose files ==="
find . -name 'docker-compose.yaml' -type f 2>/dev/null | head -20
Length of output: 752
Fix PostgreSQL volume mount paths in both docker-compose files to prevent data loss.
The official postgres image declares VOLUME /var/lib/postgresql/data. Mounting the parent directory (/var/lib/postgresql) causes Docker to create an anonymous volume for the data subdirectory, so the host bind mount will not persist the DB files. Both docker/web-app/docker-compose.yaml and docker/web-storefront/docker-compose.yaml currently mount at /var/lib/postgresql without setting a PGDATA override, which will cause complete data loss on container restart.
Change both volume mounts to /var/lib/postgresql/data:
volumes:
- sushi_atrium_data:/var/lib/postgresql/dataOr alternatively, set PGDATA environment variable to a custom location and mount that path instead.
🤖 Prompt for AI Agents
In docker/web-app/docker-compose.yaml around line 7 (and apply the same change
to docker/web-storefront/docker-compose.yaml), the postgres service mounts the
parent directory /var/lib/postgresql which causes Docker to create an anonymous
volume for the data subdirectory and can lead to data loss; change the service
volume mount to the explicit data directory (/var/lib/postgresql/data) so the
host volume persists the DB files, or alternatively set PGDATA to a custom path
in the container and mount that custom path on the host—update the volume entry
and/or add the PGDATA env var accordingly in both compose files.
| - 5433:5432 | ||
| volumes: | ||
| - sushi_atrium_data:/var/lib/postgresql/data | ||
| - sushi_atrium_data:/var/lib/postgresql |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the PostgreSQL volume path change is intentional.
The volume mount path changed from /var/lib/postgresql/data (the standard PostgreSQL data directory) to /var/lib/postgresql (the PostgreSQL base directory). This is a breaking change that could cause data loss or access issues in existing deployments.
Please verify:
- Is this change intentional and tested in a local environment?
- Does the new path
/var/lib/postgresqlproperly persist PostgreSQL data, or was the intent to mount at/var/lib/postgresql/data? - Is there a migration plan for existing deployments?
---
🏁 Script executed:
```shell
#!/bin/bash
# Examine the docker-compose files mentioned in the review
echo "=== Checking docker/web-storefront/docker-compose.yaml ==="
fd "docker-compose.yaml" --path "*/web-storefront/*" -x cat {}
echo ""
echo "=== Checking docker/web-app/docker-compose.yaml ==="
fd "docker-compose.yaml" --path "*/web-app/*" -x cat {}
echo ""
echo "=== Searching for migration guides or documentation ==="
fd -e md -e txt -e rst | xargs rg -l "volume|postgresql|migration" -i | head -20
Length of output: 600
🏁 Script executed:
#!/bin/bash
# Search for any comments or documentation about the volume path change
echo "=== Looking for comments about PostgreSQL volume path ==="
rg -i "sushi_atrium_data|var/lib/postgresql" -B2 -A2 --type yaml
echo ""
echo "=== Checking git history if available ==="
git log --oneline -20 -- "docker/web-storefront/docker-compose.yaml" 2>/dev/null || echo "Git history not available"
echo ""
echo "=== Checking for .env or documentation files ==="
fd -e env -e md | head -20Length of output: 1190
🌐 Web query:
PostgreSQL data directory /var/lib/postgresql vs /var/lib/postgresql/data mount point
💡 Result:
Short answer
- /var/lib/postgresql is the distro/base parent directory (used by Debian/RPM packages for versions, config, multiple clusters). [1]
- /var/lib/postgresql/data is the default PGDATA used by the official postgres Docker image (the place initdb and the server write the cluster files). You can override it with PGDATA. [2][3]
Why it matters
- If you mount a host volume on /var/lib/postgresql (the parent) you replace the container’s directory tree (hiding expected subdirs and init files) and may break initdb or cause the container to reinitialize the database. Mounting the specific data directory that Postgres expects (or setting PGDATA to a stable subpath such as /var/lib/postgresql/data/pgdata) avoids that problem. [2][3]
Recommendation
- For packages: use the distro’s cluster path (e.g. /var/lib/postgresql//main) or check PGDATA used by your service manager.
- For Docker: bind/mount the container volume to the image’s PGDATA (default /var/lib/postgresql/data) or explicitly set PGDATA and mount that subdirectory (e.g. /var/lib/postgresql/data/pgdata) to avoid ownership/empty-dir/initdb issues. [2][3]
Sources
[1] PostgreSQL docs — PGDATA / database file layout.
[2] Official postgres Docker image docs (PGDATA default /var/lib/postgresql/data).
[3] Docker-library/postgres discussion and StackOverflow answers about mounting /var/lib/postgresql vs /var/lib/postgresql/data.
🏁 Script executed:
#!/bin/bash
# Check PGDATA and related environment variables in both compose files
echo "=== Full docker-compose.yaml files with environment variables ==="
cat docker/web-storefront/docker-compose.yaml
echo ""
echo "=== Checking for PGDATA or other postgres env vars ==="
rg -i "PGDATA|POSTGRES_" --type yaml -B1 -A1Length of output: 996
Volume mount misconfiguration will break PostgreSQL data persistence.
The current mount at /var/lib/postgresql replaces the container's entire directory tree and breaks the initdb process, as the official postgres Docker image expects PGDATA at /var/lib/postgresql/data. No PGDATA override is set in the compose file.
Fix by either:
- Change volume mount to
sushi_atrium_data:/var/lib/postgresql/data - OR add
PGDATA: /var/lib/postgresql/data/pgdata(or similar) to environment and mount that subdirectory
🤖 Prompt for AI Agents
In docker/web-storefront/docker-compose.yaml around line 7 the volume is mounted
to /var/lib/postgresql which overwrites the container's whole directory tree and
breaks Postgres initdb; fix by either changing the mount to
sushi_atrium_data:/var/lib/postgresql/data so it maps the expected PGDATA
directory, OR set PGDATA (for example PGDATA=/var/lib/postgresql/data/pgdata) in
the service environment and update the volume to mount that exact subdirectory
(sushi_atrium_data:/var/lib/postgresql/data or
sushi_atrium_data:/var/lib/postgresql/data/pgdata) so Postgres can initialize
and persist data correctly.
| '@iconify-json/simple-icons': ^1.2.55 | ||
| '@nuxt/devtools': ^2.6.5 | ||
| '@iconify-json/simple-icons': ^1.2.56 | ||
| '@nuxt/devtools': ^3.0.0 |
There was a problem hiding this comment.
🧩 Analysis chain
Verify @nuxt/devtools v3.0.0 compatibility and breaking changes.
The upgrade from v2.6.5 to v3.0.0 is a major version bump with potential breaking changes. Ensure the codebase is compatible with the new API and that no build or development tooling breaks.
🌐 Web query:
What are the breaking changes in @nuxt/devtools 3.0.0?
💡 Result:
I couldn't find a release 3.0.0 for @nuxt/devtools. The official module docs and npm listing show Nuxt DevTools v2 (and nightly builds) — no published v3.0.0 release notes or changelog exist. [1][2]
Sources:
- Nuxt DevTools module docs (installation / versions). [1]
- @nuxt/devtools npm / package page (no v3 release listed). [2]
Verify version reference: @nuxt/devtools v3.0.0 does not exist as a published release.
No v3.0.0 release exists on npm or in the official Nuxt DevTools documentation—only v2 releases are available. The codebase references a version that cannot be resolved. Confirm this is not a typo (should remain v2.x) or clarify if this is an intended pre-release reference. This will cause dependency resolution failures.
🤖 Prompt for AI Agents
In pnpm-workspace.yaml around line 15, the dependency entry '@nuxt/devtools':
^3.0.0 references a non-existent v3.0.0 release and will break installs; confirm
whether you intended v2.x or a pre-release, then update the version to a valid
published range (e.g., ^2.x) or a valid tag/pre-release (e.g., beta) or switch
to a workspace/protocol if using a local/build artifact, save the change, run
pnpm install to verify resolution, and update the lockfile/commit the corrected
pnpm-workspace.yaml.
1 participant
Summary by CodeRabbit