redirect from createSharedPathnamesNavigation doesn't handle relative paths

[loudwinston]

Description

When using createSharedPathnamesNavigation with app router, the exported redirect function doesn't handle relative redirects.

For example, if the URL is /[locale]/foo/bar/baz, and we call redirect(.) in page.tsx, I would expect to be taken to /[locale]/foo/bar. This works with the built-in Next redirect function

In this scenario, the next-intl redirect function will instead change the URL to [locale]. (e.g. /de.)

My team has worked around this by creating a custom redirect function that wraps the one from createSharedPathnamesNavigation to handle this specific scenario (and also work around TS never issues as mentioned in #823 ), so no huge urgency to fix. But I wanted to raise this bug in the hope that it could be fixed in next-intl and we can remove our workarounds in the future.

Verifications

• I've verified that the problem I'm experiencing isn't covered in the docs.
• I've searched for similar, existing issues on GitHub and Stack Overflow.
• I've compared my app to a working example to look for differences.

Mandatory reproduction URL

Attached as ZIP file as company policy prevents me from deploying this anywhere

next-intl-redirect-bug-reproduction.zip

Reproduction description

Steps to reproduce:

1. Download reproduction repo ZIP file, extract and run npm install
2. Run npx next dev
3. Load http://localhost:3000/en/redirect/to/parent/next-intl

User is redirected to http://localhost:3000/en.

Expected behaviour

Expected that user should be redirected to http://localhost:3000/en/redirect/to/parent. You can see this by going to http://localhost:3000/en/redirect/to/parent/next, which uses the redirect function from next/navigation rather than the next-intl verison

[amannn]

Hey @loudwinston, thanks a bunch for the report and the great reproduction! Link already handled this case correctly, but this handling wasn't applied to redirect yet. A fix is coming in #1178!