Update all dependencies and devDependencies to latest versions#50
Conversation
- Bumped versions for @bull-board, @logtail, axios, argon2, class-validator, compression, cors, csrf-csrf, ejs, env-cmd, envalid, express, express-rate-limit, helmet, ioredis, jest-stare, joi, jsonwebtoken, mailgen, morgan, nodemailer, pg, swagger-jsdoc, tslib, ua-parser-js. - Updated devDependencies for @nx packages, @swc/helpers, @types packages, @typescript-eslint packages, esbuild, eslint, jest, maildev, nx, prettier, ts-jest, ts-node, typescript.
Reviewer's GuideThis pull request updates all runtime dependencies and devDependencies to their latest versions, most notably upgrading Express from v4 to v5, TypeScript to v6, Prettier to v3, ESLint to v10, and aligning related @types and Nx/Jest tooling versions, with all changes captured in package.json and package-lock.json. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 3 issues, and left some high level feedback:
- The jump from express 4.x/@types/express 4.x to express 5.x/@types/express 5.x is potentially breaking; please verify that your route handlers, error middleware, and any code relying on the old callback-based APIs are updated to the new signatures and behavior.
- Upgrading to TypeScript 6.x along with @types/node 25.x and the latest @typescript-eslint/eslint-plugin/eslint may require tsconfig and lint config tweaks (e.g., lib/target, strictness options, parserOptions) to avoid new type or lint errors; consider committing those configuration changes alongside this dependency bump.
- Several runtime libs were bumped across major versions (e.g., nodemailer 6→8, csrf-csrf 3→4, env-cmd 10→11); it may be safer to split these into separate PRs by concern (transport/email, security/middleware, tooling) so that any incompatibilities are easier to isolate and roll back.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The jump from express 4.x/@types/express 4.x to express 5.x/@types/express 5.x is potentially breaking; please verify that your route handlers, error middleware, and any code relying on the old callback-based APIs are updated to the new signatures and behavior.
- Upgrading to TypeScript 6.x along with @types/node 25.x and the latest @typescript-eslint/eslint-plugin/eslint may require tsconfig and lint config tweaks (e.g., lib/target, strictness options, parserOptions) to avoid new type or lint errors; consider committing those configuration changes alongside this dependency bump.
- Several runtime libs were bumped across major versions (e.g., nodemailer 6→8, csrf-csrf 3→4, env-cmd 10→11); it may be safer to split these into separate PRs by concern (transport/email, security/middleware, tooling) so that any incompatibilities are easier to isolate and roll back.
## Individual Comments
### Comment 1
<location path="package.json" line_range="38" />
<code_context>
+ "ejs": "^6.0.1",
+ "env-cmd": "^11.0.0",
+ "envalid": "^8.1.1",
+ "express": "5.2.1",
+ "express-rate-limit": "^8.5.2",
+ "helmet": "^8.2.0",
</code_context>
<issue_to_address>
**issue (bug_risk):** Express 5 is a major bump and may require code changes for middleware and routing.
Express 5 introduces subtle breaking changes (async handler behavior, error-handling middleware signatures, removed/changed APIs). Please verify that custom middleware, error handlers, and any use of `next('route')` or deprecated Express 4 APIs have been updated so routes and error flows behave as expected at runtime.
</issue_to_address>
### Comment 2
<location path="package.json" line_range="34" />
<code_context>
- "express-rate-limit": "^7.5.0",
- "helmet": "^8.1.0",
+ "cors": "^2.8.6",
+ "csrf-csrf": "^4.0.3",
+ "ejs": "^6.0.1",
+ "env-cmd": "^11.0.0",
</code_context>
<issue_to_address>
**🚨 issue (security):** The csrf-csrf v4 upgrade may change how tokens/cookies are generated and validated.
Since this is a major version upgrade of a security-sensitive library, please double-check our CSRF setup against the v4 docs: cookie names/paths, token extraction, same-site behavior, and secret management. Any change in defaults or token format could either break valid requests or silently reduce CSRF protection, so confirming compatibility is important.
</issue_to_address>
### Comment 3
<location path="package.json" line_range="79" />
<code_context>
+ "@types/joi": "^17.2.3",
+ "@types/jsonwebtoken": "^9.0.10",
+ "@types/morgan": "^1.9.10",
+ "@types/node": "~25.9.1",
+ "@types/nodemailer": "^8.0.0",
"@types/swagger-jsdoc": "^6.0.4",
</code_context>
<issue_to_address>
**question (bug_risk):** Node 25 type definitions might not match the actual Node runtime version in use.
If your prod/dev Node versions are older than 25, these types may expose APIs that don’t exist at runtime, leading to type-safe code that still fails in production. Consider setting `@types/node` to the minimum Node version you actually support so the type surface matches your runtime capabilities.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| "ejs": "^6.0.1", | ||
| "env-cmd": "^11.0.0", | ||
| "envalid": "^8.1.1", | ||
| "express": "5.2.1", |
There was a problem hiding this comment.
issue (bug_risk): Express 5 is a major bump and may require code changes for middleware and routing.
Express 5 introduces subtle breaking changes (async handler behavior, error-handling middleware signatures, removed/changed APIs). Please verify that custom middleware, error handlers, and any use of next('route') or deprecated Express 4 APIs have been updated so routes and error flows behave as expected at runtime.
| "express-rate-limit": "^7.5.0", | ||
| "helmet": "^8.1.0", | ||
| "cors": "^2.8.6", | ||
| "csrf-csrf": "^4.0.3", |
There was a problem hiding this comment.
🚨 issue (security): The csrf-csrf v4 upgrade may change how tokens/cookies are generated and validated.
Since this is a major version upgrade of a security-sensitive library, please double-check our CSRF setup against the v4 docs: cookie names/paths, token extraction, same-site behavior, and secret management. Any change in defaults or token format could either break valid requests or silently reduce CSRF protection, so confirming compatibility is important.
| "@types/joi": "^17.2.3", | ||
| "@types/jsonwebtoken": "^9.0.10", | ||
| "@types/morgan": "^1.9.10", | ||
| "@types/node": "~25.9.1", |
There was a problem hiding this comment.
question (bug_risk): Node 25 type definitions might not match the actual Node runtime version in use.
If your prod/dev Node versions are older than 25, these types may expose APIs that don’t exist at runtime, leading to type-safe code that still fails in production. Consider setting @types/node to the minimum Node version you actually support so the type surface matches your runtime capabilities.
Summary by Sourcery
Update runtime and development dependencies to their latest major and minor versions across the project.
Build: