docs: Update Clerk integration example to Clerk Core 2

[gcascio]

Clerk recently release Clerk Core 2 wich changes the procedure of integrating with next-intl. This PR updates the docs to reflect these changes.

[vercel]

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	Apr 29, 2024 8:11am
next-intl-example-app-router	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 29, 2024 8:11am

[vercel]

@gcascio is attempting to deploy a commit to the next-intl Team on Vercel.

A member of the Team first needs to authorize it.

[amannn]

Many thanks for proposing this update @gcascio! 🙌

[amannn]

This doesn't seem to be used.

[gcascio]

Yes you are correct, I removed it.

[amannn]

Is there a need to update the matcher from the previous value? Generally, we recommend a matcher based on available locales as this is safer than checking for requests not containing a dot for example.

Suggested change

	/**
	* Match all paths except of internal /_next/ routes, static files and api paths
	*/
	matcher: ['/((?!.+\\.[\\w]+$|_next).*)', '/', '/(api)(.*)'],
	// Match only internationalized pathnames
	matcher: ['/', '/(de|en)/:path*']

[gcascio]

The idea is that the clerk middleware runs on all page routes ensuring that auth checks are performed. Alternatively one could manually ensure that the matcher covers all protected routes, something like this:

const isProtectedRoute = createRouteMatcher([
  '/(de|en)/dashboard(.*)',
]);

// ...

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

Maybe the above would be good for the current example, while more sophisticated use cases should be handled individually. WDYT?

[amannn]

Hmm, that's a good point.

Previously we had:

  publicRoutes: ['/:locale', '/:locale/sign-in']

The updated docs now include:

const isProtectedRoute = createRouteMatcher([
  'dashboard/(.*)',
]);

At least in the default config of next-intl, there should be a locale prefix for every route. That's also what the default matcher I've mentioned above assumes.

Does Clerk still support a pattern like /:locale? Or would this be /[\w-]+/dashboard(.*) with the new config to assume a locale prefix? If we don't need to hardcode locales that's a good thing, the Next.js matcher unfortunately requires a static config.

Do you have an app where you've upgraded to the latest Clerk version and is this working for you?

[gcascio]

Yes Clerk still does support the mentioned path pattern!

I upgraded a production app to the latest Clerk version without issues so far, unfortunately it is closed source. The biggest change IMHO ist that now by default, clerkMiddleware treats all pages as public.

I just created a test repo to play around, you can find it here. There I used the /:locale pattern in the clerk middleware which looks like this:

import createMiddleware from 'next-intl/middleware';
import {
  clerkMiddleware,
  createRouteMatcher,
} from '@clerk/nextjs/server';

const intlMiddleware = createMiddleware({
  locales: ['en', 'de'],
  defaultLocale: 'en'
});

const isProtectedRoute = createRouteMatcher([
  '/:locale/dashboard(.*)',
]);

export default clerkMiddleware((auth, req) => {
  if (isProtectedRoute(req)) auth().protect();

  return intlMiddleware(req);
});

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

I think this is as close as it gets to the previous example, if I am not missing something.

[amannn]

Ah yes, that looks perfect from my perspective! Would you mind updating the PR again with that snippet? Happy to merge then!

[gcascio]

Great, I updated the PR!

[amannn]

Just some formatting nits to be consistent, I'll apply the suggestions from the GitHub UI.