Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: next-intl@4 #1412

Draft
wants to merge 102 commits into
base: main
Choose a base branch
from
Draft

feat!: next-intl@4 #1412

wants to merge 102 commits into from

Conversation

amannn
Copy link
Owner

@amannn amannn commented Oct 9, 2024

Changes

TODO

  • docs: Adapt examples for rootParams #1619 (in case this becomes available and reliable)
  • Remove/adapt beta banner
  • Update blog post
    • Revert v4 domain
    • Remove "beta"
    • Thanks for beta testing, please carefully review if there were updates
  • Adapt docs for better search (i.e. use APIs as headlines more)

Related

Resolves #1153
Resolves #1452
Resolves #410
Resolves #779
Resolves #1464
Resolves #1670
Resolves #1694

Sorry, something went wrong.

amannn and others added 20 commits June 20, 2024 16:08
This reverts commit 47239f9.
…currently active pathname for localized pathnames
# Conflicts:
#	packages/next-intl/src/middleware/utils.test.tsx
#	packages/next-intl/src/shared/utils.test.tsx
…is rendered from a Server Component (#1191)

This should ease the transition from Server to Client Components, as you
don't have to manually pass this prop anymore. If you've previously
passed this prop manually, you can remove this assignment now.

If this is not desired (e.g. because you have a large `formats` object
that you don't want to pass to the client side), you can manually
opt-out via `formats={{}}` on `NextIntlClientProvider` in order to not
provide any formats on the client side.

**BREAKING CHANGE:** There's a very rare chance where this can break
existing behavior. If you're rendering `NextIntlClientProvider` in a
Server Component, you rely on static rendering, but you're not using
`unstable_setRequestLocale` (i.e. you're using hooks like
`useTranslations` exclusively in Client Components), this can opt your
page into dynamic rendering. If this affects you, please provide the
`formats` prop explicitly to `NextIntlClientProvider`.
Copy link

vercel bot commented Oct 9, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
next-intl-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 18, 2025 11:43am
next-intl-example-app-router ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 18, 2025 11:43am
next-intl-example-app-router-without-i18n-routing ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 18, 2025 11:43am

@amannn amannn changed the title next-intl@4 feat!: next-intl@4 Oct 9, 2024
@amannn amannn added v4 and removed v4 labels Oct 9, 2024
If you have nested providers, previously only the configuration of the
innermost one would be applied.

With this change, configuration is now passed from one provider to the
next, while allowing to override individual props.

**BREAKING CHANGE:** There's a very rare chance that this change affects
your app, but in case you've previously relied on providers not
inheriting from each other, you now have to reset props manually in case
you want to retain the prev. behavior.
# Conflicts:
#	packages/next-intl/.size-limit.ts
…epo support (#1700)

Resolves: #1699

This change renames "createMessagesDeclaration" to
"createMessagesDeclarations" and changes the type to an array. Each
entry of the array will be used to create message declaration files.
Supporting multiple message files helps to use next-intl in monorepo
setups.

Since v4 is in beta, I renamed the property and removed support for a
single string. To me, clean types lead to cleaner code. If compatibility
is a more of a concern during the beta phase, I could not change the
property name and keep the support for single strings. Please let me
know.

---------

Co-authored-by: Jan Amann <jan@amann.work>
# Conflicts:
#	docs/src/pages/docs/usage/configuration.mdx
#	lerna.json
… `localePrefix: 'always'` and update middleware matcher suggestion in docs (#1720)

Previously, we suggested a middleware matcher that looked like this:

```tsx
// middleware.ts

export const config = {
  // Match only internationalized pathnames
  matcher: ['/', '/(de|en)/:path*']
};
```

Even though the hardcoded locales need to be updated when new locales
are added, this was suggested in light of providing an error-free
getting started experience.

However, based on the apps I've seen over time, it seems like this
choice was unpopular and users typically go for a matcher that looks
like this:

```tsx
export const config = {
  // Match all pathnames except for
  // - … if they start with `/api`, `/_next` or `/_vercel`
  // - … the ones containing a dot (e.g. `favicon.ico`)
  matcher: '/((?!api|_next|_vercel|.*\\..*).*)'
};
```

While this avoids hardcoding locales, it requires extra care to [match
pathnames that contain a
dot](https://next-intl.dev/docs/routing/middleware#matcher-config) (e.g.
`/users/jane.doe`).

To align better with user expectations, we now suggest the negative
lookahead in the getting started docs and point out the case with
pathnames containing dots. As an extra benefit, it makes it
significantly easier to switch between routing strategies and add custom
prefixes.

With the new matcher in place, the middleware now also returns an
`x-default` [alternate
link](https://next-intl.dev/docs/routing#alternate-links-details) for
non-root pathnames (previously only one for `/` was returned when using
`localePrefix: 'always'`). Due to this, please update your middleware
matcher as shown in the [getting started
docs](https://next-intl.dev/docs/getting-started/app-router/with-i18n-routing#middleware)
if you're using alternate links.

**Related discussions:**
- #1136
- #505
- #504
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment