Backend up npm libs#1593
Conversation
There was a problem hiding this comment.
Pull request overview
Updates Node.js dependencies across the backend and shared library, and refreshes the autoadmin websocket server’s dependency set/lockfile and container build setup.
Changes:
- Bump various backend and shared-code npm dependencies (AWS SDK, DB drivers, HTTP/libs, Nest, LangChain/OpenAI, etc.).
- Update autoadmin-ws-server dependencies and regenerate its
yarn.lockin Yarn Berry lockfile format. - Update autoadmin-ws-server Dockerfile base image to Node 24 and adjust install commands.
Reviewed changes
Copilot reviewed 4 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| shared-code/package.json | Dependency version bumps for shared library packages. |
| backend/package.json | Dependency/devDependency version bumps for backend service. |
| autoadmin-ws-server/package.json | Dependency/devDependency bumps for websocket server. |
| autoadmin-ws-server/yarn.lock | Lockfile regenerated/converted to Yarn Berry format. |
| autoadmin-ws-server/Dockerfile | Node image version update and changes to Yarn install commands. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| COPY package.json yarn.lock ./ | ||
| RUN yarn install --frozen-lockfile | ||
| RUN yarn install |
There was a problem hiding this comment.
The Docker build context only copies package.json and yarn.lock, but this yarn.lock is Yarn Berry-style (has __metadata). Without copying a .yarnrc.yml/.yarn (or using corepack + a packageManager field), yarn install may run Yarn classic and fail to parse the lockfile or install with the wrong linker (PnP vs node-modules). Pin and activate the intended Yarn version and ensure node-modules linking for runtime resolution.
|
|
||
| COPY package.json yarn.lock ./ | ||
| RUN yarn install --frozen-lockfile | ||
| RUN yarn install |
There was a problem hiding this comment.
To keep Docker builds reproducible, use Yarn's lockfile-enforcing mode (e.g., --immutable) for installs. Dropping --frozen-lockfile means the image build can silently modify the dependency tree when the lockfile and manifest drift.
|
|
||
| COPY package.json yarn.lock ./ | ||
| RUN yarn install --frozen-lockfile --production && yarn cache clean | ||
| RUN yarn install --production && yarn cache clean |
There was a problem hiding this comment.
Same as the builder stage: the production install should be lockfile-immutable as well. Otherwise the final runtime image can be built with a dependency graph that differs from what was tested/built in CI.
| RUN yarn install --production && yarn cache clean | |
| RUN yarn install --production --frozen-lockfile && yarn cache clean |
| "dependencies": { | ||
| "@hono/node-server": "^1.19.9", | ||
| "hono": "^4.11.7", | ||
| "hono": "^4.11.9", | ||
| "jsonwebtoken": "^9.0.3", | ||
| "lru-cache": "^11.2.5", | ||
| "lru-cache": "^11.2.6", | ||
| "nanoid": "^5.1.6", | ||
| "pino": "^10.3.0", | ||
| "pino": "^10.3.1", | ||
| "ws": "^8.19.0", | ||
| "zod": "^4.3.6" | ||
| }, | ||
| "devDependencies": { | ||
| "@biomejs/biome": "2.3.13", | ||
| "@biomejs/biome": "2.3.14", |
There was a problem hiding this comment.
This package uses a Yarn Berry lockfile format, but package.json doesn't declare a packageManager to tell Corepack which Yarn major to use. Adding packageManager (consistent with the repo's Yarn 3.4.1) would prevent yarn resolving to an incompatible Yarn 1.x in CI/Docker and makes installs deterministic.
No description provided.