Chore: Upgrade Next.js and React packages due to CVE-2025-66478

[raisiqueira]

Description

Upgraded the Next.js and React packages due to a CVE that allows remote code execution.

Motivation and Context

• https://nextjs.org/blog/CVE-2025-66478

Screenshots (if appropriate):

Steps to reproduce (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires documentation updates.
• I have updated the documentation accordingly.
• My change requires dependencies updates.
• I have updated the dependencies accordingly.

Summary by Sourcery

Upgrade the Next.js frontend stack to the latest Next/React versions and align project config with the new tooling requirements.

Build:

• Bump Next.js, React, React DOM, and related Next/ESLint/type packages to newer versions and update type overrides accordingly.
• Switch Next.js config to use the new Turbopack hook instead of the legacy webpack hook.
• Add a pnpm workspace configuration restricting built dependencies to sharp.
• Adjust TypeScript and Tailwind configurations to match the updated Next.js/React setup, including JSX mode and type includes.

[sourcery-ai]

Reviewer's Guide

Upgrades the Next.js/React stack to address a security CVE and aligns project configuration (TypeScript, Next config, middleware/proxy, Tailwind, and pnpm workspace) with the newer tooling expectations.

Flow diagram for updated TypeScript, JSX, and Next config pipeline

flowchart LR
  TSConfig[TSConfig
  jsx: react-jsx
  moduleResolution: bundler] --> TSCompiler[TypeScript compiler]

  TSCompiler --> Turbopack[Turbopack bundler
  nextConfig.turbopack]

  Turbopack --> ForkTsChecker[ForkTsCheckerWebpackPlugin]
  Turbopack --> NextRuntime[Next.js runtime 16.0.7]

  NextRuntime --> ReactRuntime[React 19.2.1
  ReactDOM 19.2.1]

  NextRuntime --> DevTypes[Next dev type files
  .next/dev/types]

  TailwindConfig[Tailwind config
  tailwind.config.js] --> TailwindCLI[Tailwind CLI]
  TailwindCLI --> Turbopack

  pnpm[pnpm with workspace
  pnpm-workspace.yaml] --> TSCompiler
  pnpm --> Turbopack
  pnpm --> TailwindCLI

Loading

File-Level Changes

Change	Details	Files
Upgrade Next.js, React, and related type/eslint packages to secure versions and keep tooling in sync.	Bump next, react, and react-dom to newer major/minor versions addressing the CVE. Update @next/eslint-plugin-next and eslint-config-next to versions compatible with the new Next.js release. Align @types/react and @types/react-dom versions in both devDependencies and overrides with the upgraded React version. Regenerate or adjust lockfile to match the upgraded dependencies.	nextjs-frontend/package.json nextjs-frontend/package-lock.json
Adjust TypeScript configuration for the newer Next/React toolchain and dev types.	Switch JSX compiler option from preserve to react-jsx to match modern React JSX transform expectations. Reformat and slightly expand tsconfig.json arrays for lib, paths, include, and exclude for readability and tooling compatibility. Add .next/dev/types/**/*.ts to the TypeScript include list so dev-time types are picked up.	nextjs-frontend/tsconfig.json
Update Next.js configuration hook from webpack to turbopack while preserving the type-checking plugin for client builds.	Rename the custom bundler hook from webpack to turbopack to match Next.js 16 configuration API. Keep the ForkTsCheckerWebpackPlugin integration for non-server builds within the new hook.	nextjs-frontend/next.config.mjs
Rename middleware entrypoint to a proxy handler, updating the exported function name accordingly.	Rename middleware.ts to proxy.ts to reflect its role as a proxy handler. Change the exported function name from middleware to proxy while keeping the cookie/token logic intact.	nextjs-frontend/middleware.ts nextjs-frontend/proxy.ts
Minor tooling and lint-related tweaks for Tailwind, watcher script, and pnpm workspace configuration.	Add an ESLint disable comment above the Tailwind plugin require to satisfy TypeScript-oriented lint rules. Remove a redundant blank line in watcher.js to clean up lint/style. Introduce pnpm-workspace.yaml with onlyBuiltDependencies configured for sharp to optimize dependency builds in the workspace.	nextjs-frontend/tailwind.config.js nextjs-frontend/watcher.js nextjs-frontend/pnpm-workspace.yaml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Renaming middleware.ts to proxy.ts and changing the exported function from middleware to proxy will disable Next.js middleware routing entirely (Next expects a middleware.ts file with a middleware export at the app root), so if this is meant to continue running as middleware it should keep the conventional filename and export name.
• Switching from the webpack property to turbopack in next.config.mjs while still adding ForkTsCheckerWebpackPlugin (a webpack plugin) likely means this config no longer runs as intended; consider either keeping the webpack config hook or adopting a Turbopack-compatible approach for type-checking.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Renaming `middleware.ts` to `proxy.ts` and changing the exported function from `middleware` to `proxy` will disable Next.js middleware routing entirely (Next expects a `middleware.ts` file with a `middleware` export at the app root), so if this is meant to continue running as middleware it should keep the conventional filename and export name.
- Switching from the `webpack` property to `turbopack` in `next.config.mjs` while still adding `ForkTsCheckerWebpackPlugin` (a webpack plugin) likely means this config no longer runs as intended; consider either keeping the `webpack` config hook or adopting a Turbopack-compatible approach for type-checking.

## Individual Comments

### Comment 1
<location> `nextjs-frontend/next.config.mjs:5-8` </location>
<code_context>
 /** @type {import('next').NextConfig} */
 const nextConfig = {
-  webpack: (config, { isServer }) => {
+  turbopack: (config, { isServer }) => {
     if (!isServer) {
       config.plugins.push(
         new ForkTsCheckerWebpackPlugin({
</code_context>

<issue_to_address>
**issue (bug_risk):** Using `turbopack` instead of `webpack` here is likely unsupported and breaks the ForkTsChecker setup.

NextConfig doesn’t expose a `turbopack` hook equivalent to `webpack`, and `ForkTsCheckerWebpackPlugin` only works with webpack. With this change, Next will ignore the function so the type-checking plugin never runs. Keep this under `webpack` if you still rely on this plugin, or find a different solution for incremental type-checking when using Turbopack.
</issue_to_address>

### Comment 2
<location> `nextjs-frontend/tsconfig.json:17` </location>
<code_context>
     "resolveJsonModule": true,
     "isolatedModules": true,
-    "jsx": "preserve",
+    "jsx": "react-jsx",
     "incremental": true,
     "plugins": [
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Switching `jsx` from `preserve` to `react-jsx` can conflict with Next’s own JSX/SWC handling.

Next’s toolchain (via SWC) generally assumes `"jsx": "preserve"` so it can own the JSX transform, particularly around app router and server/client component boundaries. Moving this to `"react-jsx"` shifts that work into TypeScript and can introduce subtle runtime/build issues. Please confirm this aligns with Next 16’s guidance and your bundling behavior; otherwise, consider keeping `"jsx"` as `"preserve"`.

```suggestion
    "jsx": "preserve",
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (bug_risk): Switching jsx from preserve to react-jsx can conflict with Next’s own JSX/SWC handling.

Next’s toolchain (via SWC) generally assumes "jsx": "preserve" so it can own the JSX transform, particularly around app router and server/client component boundaries. Moving this to "react-jsx" shifts that work into TypeScript and can introduce subtle runtime/build issues. Please confirm this aligns with Next 16’s guidance and your bundling behavior; otherwise, consider keeping "jsx" as "preserve".

Suggested change

	"jsx": "react-jsx",
	"jsx": "preserve",

[fjsj]

Thanks, please check comments

[andersonresende]

@raisiqueira could you fix the conflicts and follow the release process?
https://nextfastapi.com/contributing/#release

[raisiqueira]

@andersonresende Done ✅

[andersonresende]

Thanks! I'll approve!