Moving from a pages router page to app directory through NextLink duplicates base path on built app
Verify canary release
- [X] I verified that the issue exists in the latest Next.js canary release
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 22.5.0: Mon Apr 24 20:53:19 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6020
Binaries:
Node: 18.14.0
npm: 9.3.1
Yarn: 1.22.19
pnpm: N/A
Relevant Packages:
next: 13.4.20-canary.12
eslint-config-next: 13.4.19
react: 18.2.0
react-dom: 18.2.0
typescript: 5.1.6
Next.js Config:
output: N/A
Which area(s) of Next.js are affected? (leave empty if unsure)
App Router, Routing (next/router, next/navigation, next/link)
Link to the code that reproduces this issue or a replay of the bug
https://github.com/Artsu/next-app-directory-with-legacy-pages-router
To Reproduce
- run
npm install - run
npm run build - run
npm start - open site at
http://localhost:3000/demo - click the
Pages examplelink, this works - click the
Landing pagelink. The url is http://localhost:3000/demo but it opens http://localhost:3000/demo/demo instead
Describe the Bug
In a project with set basePath that uses both app directory and legacy pages router, any next/link from legacy page to app directory page will have the correct route when hovered in browser but duplicates the base path when clicked. This only happens on built site running next start or on exported static site. On development mode with next dev the issue does not occur
Expected Behavior
After clicking the link users should be correctly directed to the app directory page with the basePath only getting added once
Which browser are you using? (if relevant)
Firefox 116.0.2 (64-bit)
How are you deploying your application? (if relevant)
next start, static s3
Having this same issue.
However a little bit different. Simply by adding the app directory and a basic route handler that just contains:
export async function GET() {
return new Response('Ok', {
status: 200,
});
}
And this breaks some NextLink's in the legacy pages router which simply links to other legacy pages. Nothing links to the new app directory.
The links are broken in the same way as described above, when hovering the link in the browser it shows correctly, but when clicking you get routed to another URL with the basePath applied twice.
If I just remove basePath or the app directory it all works.
Tried several versions since the app directory was enabled. Latest canary does not solve the issue.
We use basePath to be able to deploy the app on a subpath and we want to start using the app directory for new functionality, but we can't if it breaks the old pages directory.
EDIT: My issue seems to be tied to Route handlers. As soon as I tried to just add a app/test/page.tsx dummy page which just returns an empty component (still not linking to it) my Links in the legacy pages router starts working again.
Tried removing the dummy page and experimenting other stuff, but it's consistently fixed and broken depending on the existence of the "dummy page".
I'm having the same issue (using both pages and app), and for me it seems to specifically break a page with an underscore in the name, all other pages seem fine. In fact, I just renamed it from about/my_page.tsx to about/my-page.tsx and the issue seems to be fixed.
I had this issue as well, although on direct router calls (router.replace), which the Link component uses internally so it seems fair to assume there is a link (pun intended).
The extra basePath is applied here: https://github.com/vercel/next.js/blob/3f20b46b59c6a91fed562cffc842e1db79727539/packages/next/src/shared/lib/router/router.ts#L1069
It was already added to the URL here: https://github.com/vercel/next.js/blob/3f20b46b59c6a91fed562cffc842e1db79727539/packages/next/src/shared/lib/router/router.ts#L131
I was looking at this again today and found #47486 , so far the suggested fix from crisvergara of setting clientRouterFilterAllowedRate: 0.000001 in next.config.js seems to be working for me.
I found bug about Link with basePath #66660 maybe this is related
This issue has been automatically marked as stale due to inactivity. It will be closed in 7 days unless there’s further input. If you believe this issue is still relevant, please leave a comment or provide updated details. Thank you.
This issue has been automatically closed due to inactivity. If you’re still experiencing a similar problem or have additional details to share, please open a new issue following our current issue template. Your updated report helps us investigate and address concerns more efficiently. Thank you for your understanding!