Release

[philipbrembeck]

Summary by Sourcery

Upgrade the app to Next.js 16 and React 19 stable while modernizing linting, internationalization, and CI tooling, and adding Portuguese (Brazil) locale support.

New Features:

• Add support for the pt-br locale across routing, navigation, and locale files.
• Introduce a next-intl navigation helper module and proxy middleware configuration for locale-aware routing.

Bug Fixes:

• Ensure pnpm-based Docker builds consistently enable Corepack before installing dependencies or running builds.

Enhancements:

• Refactor ESLint configuration to use flat config with eslint-config-next, typescript-eslint, and explicit rules and ignores, and switch lint scripts to call eslint directly.
• Update TypeScript configuration for React 19 (react-jsx) and include Next.js dev type paths.
• Adjust Quagga type declaration files to satisfy linting rules while preserving any-typed exports.
• Update the README translation badge to use a static shields.io badge.

Build:

• Upgrade core framework and tooling dependencies, including Next.js to 16, React and React DOM to 19.2, next-intl to v4, eslint-config-next to 16, and related @types packages, and add typescript-eslint while removing legacy @typescript-eslint packages.
• Refresh pnpm lockfile and project metadata to align with the new dependency set.

CI:

• Bump GitHub Actions versions (checkout, setup-node, and Docker actions) in build and PR workflows to their latest major revisions for improved reliability and support.

Deployment:

• Update Dockerfile commands to install the latest Corepack globally before enabling pnpm in both dependency installation and build stages.

Documentation:

• Add AGENTS.md and CLAUDE.md to document development commands, architecture, testing strategy, styling conventions, and i18n guidelines.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sourcery-ai]

Reviewer's Guide

Modernizes linting and type tooling, upgrades Next.js/React/next-intl and CI/docker actions, and extends internationalization (including pt-br) while refining project documentation for agents and contributors.

Updated class diagram for i18n routing, navigation, and proxy modules

classDiagram
  class routing_module {
    +routing
  }

  class navigation_module {
    +Link
    +redirect
    +usePathname()
    +useRouter()
    +getPathname()
  }

  class proxy_module {
    +default_middleware
    +config
  }

  routing_module <.. navigation_module : uses_routing
  routing_module <.. proxy_module : uses_routing

Loading

File-Level Changes

Change	Details	Files
Refactor ESLint configuration to use flat config with eslint-config-next presets and typescript-eslint, and adjust lint scripts accordingly.	Replace manual plugin-based ESLint setup with spread of eslint-config-next core-web-vitals and typescript presets Migrate to typescript-eslint unified package for parser and strict/stylistic rule sets Retain and adapt custom rules for react-compiler and import/order plus some react-hooks overrides Add ignore patterns for build artifacts and generated files Update npm lint scripts to invoke eslint directly instead of next lint	eslint.config.mjs package.json
Upgrade framework and type-related dependencies to stable Next.js 16, React 19.2, next-intl 4, and align @types packages and pnpm overrides.	Bump next, react, react-dom to latest stable 16/19.2 versions Update next-intl to v4 and adjust i18n usage patterns accordingly Synchronize @types/node, @types/react, @types/react-dom versions and pnpm overrides Introduce typescript-eslint package and remove older @typescript-eslint toolchain from dev dependencies and overrides	package.json pnpm-lock.yaml
Refresh GitHub Actions workflows to newer major versions of core actions and Docker actions.	Update actions/checkout usages from v4 to v5 across build and PR workflows Upgrade actions/setup-node from v4 to v6 Update docker/login-action, docker/metadata-action, and docker/build-push-action to newer commit SHAs	.github/workflows/build.yml .github/workflows/pr.yml
Adjust TypeScript compiler configuration and suppress any-type lint errors in Quagga declaration shims.	Change JSX setting from preserve to react-jsx and slightly expand included Next.js type paths Format tsconfig.json arrays for readability and extend include/exclude lists Add ESLint disable comments for no-explicit-any in Quagga declaration files while keeping them typed as any	tsconfig.json types/@ericblade/quagga2.d.ts types/quagga.d.ts
Update i18n routing/navigation to next-intl v4 APIs, add pt-br locale, and wire navigation imports accordingly.	Simplify routing.ts to only define routing locales and defaultLocale, adding pt-br Introduce navigation helper using createNavigation and switch component imports from old createSharedPathnamesNavigation Move next-intl middleware into src/proxy.ts with explicit locale matcher and remove old src/middleware.ts Add pt-br to languages list in more page and ensure Link imports come from new navigation module Create empty pt-br locale JSON scaffold and touch other locale files via lockfile/format updates	src/i18n/routing.ts src/i18n/navigation.ts src/proxy.ts src/middleware.ts src/app/[locale]/more/page.tsx src/components/nav.tsx src/locales/pt-br.json src/locales/*.json
Improve Docker build robustness for pnpm-based installs and builds by explicitly installing and enabling corepack.	Before pnpm install/build steps, globally install latest corepack and enable pnpm instead of just enabling corepack Keep existing yarn/npm branches unchanged	Dockerfile
Enhance contributor/agent documentation and tweak badges.	Add AGENTS.md and CLAUDE.md describing commands, architecture, guidelines, and i18n behavior Update README Inlang translation badge to use a shields.io-based image	AGENTS.md CLAUDE.md README.md

---

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 and found some issues that need to be addressed.

• In the new ESLint flat config you’re still using import/order and several react-hooks/* rules but the corresponding eslint-plugin-import and eslint-plugin-react-hooks plugins are no longer registered in plugins, which will cause ESLint to error; either re-add those plugins or drop the related rules.
• package.json declares react/react-dom as 19.2.0 but pnpm.overrides still forces react/react-dom to 19.0.0-rc-*; consider aligning or removing the overrides to avoid running a different React version than the one declared in dependencies.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the new ESLint flat config you’re still using `import/order` and several `react-hooks/*` rules but the corresponding `eslint-plugin-import` and `eslint-plugin-react-hooks` plugins are no longer registered in `plugins`, which will cause ESLint to error; either re-add those plugins or drop the related rules.
- `package.json` declares `react`/`react-dom` as `19.2.0` but `pnpm.overrides` still forces `react`/`react-dom` to `19.0.0-rc-*`; consider aligning or removing the overrides to avoid running a different React version than the one declared in dependencies.

## Individual Comments

### Comment 1
<location> `src/proxy.ts:5-13` </location>
<code_context>
+
+import { routing } from "./i18n/routing";
+
+export default createMiddleware(routing);
+
+export const config = {
+  // Match all pathnames except for
+  // - … if they start with `/api`, `/trpc`, `/_next` or `/_vercel`
+  // - … the ones containing a dot (e.g. `favicon.ico`)
+  // matcher: "/((?!api|trpc|_next|_vercel|.*\\..*).*)",
+  // Match only internationalized pathnames
+  matcher: ["/", "/(de|en|es|fr|pl|cz|pt-br)/:path*"],
+};
</code_context>

<issue_to_address>
**issue (bug_risk):** Renaming `middleware.ts` to `proxy.ts` will prevent Next.js from running the middleware.

Because Next.js only auto-loads `middleware.ts` (or `src/middleware.ts`) as the edge middleware entrypoint, renaming it to `proxy.ts` disables the middleware and breaks locale routing / `next-intl` at the edge. Unless you have a custom setup that explicitly registers `proxy.ts` as middleware, keep this file named `middleware.ts` in the expected location.
</issue_to_address>

### Comment 2
<location> `tsconfig.json:19` </location>
<code_context>
     "resolveJsonModule": true,
     "isolatedModules": true,
-    "jsx": "preserve",
+    "jsx": "react-jsx",
     "incremental": true,
     "baseUrl": ".",
</code_context>

<issue_to_address>
**issue (bug_risk):** Using `"jsx": "react-jsx"` with Next.js can conflict with the framework’s own JSX/TSX transform.

Next.js expects `"jsx": "preserve"` so its SWC pipeline can perform the JSX transform. Letting TypeScript use `"react-jsx"` makes it emit JSX runtime calls itself, which can cause double transforms or subtle runtime issues (notably with the app router). Unless you’ve explicitly validated this setup, I’d revert to `"jsx": "preserve"`.
</issue_to_address>

### Comment 3
<location> `eslint.config.mjs:22-24` </location>
<code_context>
+  },
+  files: ["**/*.{js,jsx,ts,tsx}"],
+  rules: {
+    // TypeScript ESLint rules
+    ...tseslint.configs.strict.rules,
+    ...tseslint.configs.stylistic.rules,
+
+    // React Compiler
</code_context>

<issue_to_address>
**issue (bug_risk):** The referenced `tseslint.configs.strict`/`stylistic` may not match the recommended flat-config presets for `typescript-eslint` v8.

For `typescript-eslint` v8 on ESLint 9, the documented flat presets are `recommendedTypeChecked` / `strictTypeChecked` / `stylisticTypeChecked`. Depending on the meta package’s exports, `configs.strict` and `configs.stylistic` may be missing or legacy, which could cause config load failures or omit type-checked rules. Prefer the flat presets (e.g. `tseslint.configs.strictTypeChecked` / `stylisticTypeChecked`) or verify that `strict` / `stylistic` are actually present in your pinned version.
</issue_to_address>

### Comment 4
<location> `Dockerfile:14-17` </location>
<code_context>
   if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
   elif [ -f package-lock.json ]; then npm ci; \
-  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
+  elif [ -f pnpm-lock.yaml ]; then npm i -g corepack@latest && corepack enable pnpm && pnpm i --frozen-lockfile; \
   else echo "Lockfile not found." && exit 1; \
   fi
</code_context>

<issue_to_address>
**suggestion (performance):** Installing `corepack` globally twice in the Docker build adds overhead without much benefit.

Both the dependency-install and build stages now run `npm i -g corepack@latest` before enabling pnpm, adding redundant work and extra image size. Prefer installing/updating corepack once in an earlier layer and then just running `corepack enable pnpm`, or rely on the base image’s Node/corepack if available.

Suggested implementation:

```
RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi

```

` since that part of the Dockerfile isn’t shown.

Here are the concrete edits:

<file_operations>
<file_operation operation="edit" file_path="Dockerfile">
<<<<<<< SEARCH
RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then npm i -g corepack@latest && corepack enable pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then npm i -g corepack@latest && corepack enable pnpm && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi
=======
RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi
>>>>>>> REPLACE
</file_operation>
</file_operations>

<additional_changes>
To fully apply your suggestion, you should:
1. Add a single earlier layer (before these RUN blocks) that ensures corepack is installed/updated, for example:
   `RUN npm i -g corepack@latest`  
   or, if the base image already includes a suitable corepack, you can skip this.
2. If you introduce that earlier `RUN`, remove any other `npm i -g corepack@latest` occurrences elsewhere in the Dockerfile to avoid additional redundant installs.
</issue_to_address>

### Comment 5
<location> `package.json:37-30` </location>
<code_context>
     "prom-client": "^15.1.3",
-    "react": "19.0.0-rc-69d4b800-20241021",
-    "react-dom": "19.0.0-rc-69d4b800-20241021",
+    "react": "19.2.0",
+    "react-dom": "19.2.0",
     "sass": "^1.81.0",
</code_context>

<issue_to_address>
**issue (bug_risk):** The `pnpm.overrides` still pin React to a 19.0.0-rc while dependencies require 19.2.0, which can cause version drift.

Given the overrides still target `19.0.0-rc-69d4b800-20241021` for both `react` and `react-dom`, pnpm installs will continue to use the RC despite the `19.2.0` declarations. This can lead to subtle runtime or tooling/type mismatches. If the goal is to be on 19.2.0, please update or remove the overrides to keep versions consistent.
</issue_to_address>

### Comment 6
<location> `CLAUDE.md:1` </location>
<code_context>
+# AGENTS.md
+
+## Development Commands
</code_context>

<issue_to_address>
**issue (typo):** Top-level heading does not match the file name and may be a copy-paste mistake.

In `CLAUDE.md`, the H1 is `# AGENTS.md`, which appears copied from `AGENTS.md`. Please update the heading (e.g., to `# CLAUDE.md`) so the document title matches the file name.

```suggestion
# CLAUDE.md
```
</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]

issue (bug_risk): Renaming middleware.ts to proxy.ts will prevent Next.js from running the middleware.

Because Next.js only auto-loads middleware.ts (or src/middleware.ts) as the edge middleware entrypoint, renaming it to proxy.ts disables the middleware and breaks locale routing / next-intl at the edge. Unless you have a custom setup that explicitly registers proxy.ts as middleware, keep this file named middleware.ts in the expected location.

[sourcery-ai]

issue (bug_risk): Using "jsx": "react-jsx" with Next.js can conflict with the framework’s own JSX/TSX transform.

Next.js expects "jsx": "preserve" so its SWC pipeline can perform the JSX transform. Letting TypeScript use "react-jsx" makes it emit JSX runtime calls itself, which can cause double transforms or subtle runtime issues (notably with the app router). Unless you’ve explicitly validated this setup, I’d revert to "jsx": "preserve".

[sourcery-ai]

issue (bug_risk): The referenced tseslint.configs.strict/stylistic may not match the recommended flat-config presets for typescript-eslint v8.

For typescript-eslint v8 on ESLint 9, the documented flat presets are recommendedTypeChecked / strictTypeChecked / stylisticTypeChecked. Depending on the meta package’s exports, configs.strict and configs.stylistic may be missing or legacy, which could cause config load failures or omit type-checked rules. Prefer the flat presets (e.g. tseslint.configs.strictTypeChecked / stylisticTypeChecked) or verify that strict / stylistic are actually present in your pinned version.

[sourcery-ai]

suggestion (performance): Installing corepack globally twice in the Docker build adds overhead without much benefit.

Both the dependency-install and build stages now run npm i -g corepack@latest before enabling pnpm, adding redundant work and extra image size. Prefer installing/updating corepack once in an earlier layer and then just running corepack enable pnpm, or rely on the base image’s Node/corepack if available.

Suggested implementation:

RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

RUN \
  if [ -f yarn.lock ]; then yarn run build; \
  elif [ -f package-lock.json ]; then npm run build; \
  elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; \
  else echo "Lockfile not found." && exit 1; \
  fi

` since that part of the Dockerfile isn’t shown.

Here are the concrete edits:

<file_operations>
<file_operation operation="edit" file_path="Dockerfile">
<<<<<<< SEARCH
RUN
if [ -f yarn.lock ]; then yarn --frozen-lockfile;
elif [ -f package-lock.json ]; then npm ci;
elif [ -f pnpm-lock.yaml ]; then npm i -g corepack@latest && corepack enable pnpm && pnpm i --frozen-lockfile;
else echo "Lockfile not found." && exit 1;
fi

RUN
if [ -f yarn.lock ]; then yarn run build;
elif [ -f package-lock.json ]; then npm run build;
elif [ -f pnpm-lock.yaml ]; then npm i -g corepack@latest && corepack enable pnpm && pnpm run build;
else echo "Lockfile not found." && exit 1;
fi

RUN
if [ -f yarn.lock ]; then yarn --frozen-lockfile;
elif [ -f package-lock.json ]; then npm ci;
elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile;
else echo "Lockfile not found." && exit 1;
fi

RUN
if [ -f yarn.lock ]; then yarn run build;
elif [ -f package-lock.json ]; then npm run build;
elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build;
else echo "Lockfile not found." && exit 1;
fi

REPLACE
</file_operation>
</file_operations>

<additional_changes>
To fully apply your suggestion, you should:

1. Add a single earlier layer (before these RUN blocks) that ensures corepack is installed/updated, for example:
   RUN npm i -g corepack@latest
   or, if the base image already includes a suitable corepack, you can skip this.
2. If you introduce that earlier RUN, remove any other npm i -g corepack@latest occurrences elsewhere in the Dockerfile to avoid additional redundant installs.

[sourcery-ai]

issue (bug_risk): The pnpm.overrides still pin React to a 19.0.0-rc while dependencies require 19.2.0, which can cause version drift.

Given the overrides still target 19.0.0-rc-69d4b800-20241021 for both react and react-dom, pnpm installs will continue to use the RC despite the 19.2.0 declarations. This can lead to subtle runtime or tooling/type mismatches. If the goal is to be on 19.2.0, please update or remove the overrides to keep versions consistent.

[sourcery-ai]

issue (typo): Top-level heading does not match the file name and may be a copy-paste mistake.

In CLAUDE.md, the H1 is # AGENTS.md, which appears copied from AGENTS.md. Please update the heading (e.g., to # CLAUDE.md) so the document title matches the file name.

Suggested change

	# AGENTS.md
	# CLAUDE.md