vercel / next.js

The React Framework
https://nextjs.org
MIT License
127.12k stars 27.01k forks source link

App Router page with data fetching returns 404 in combination with the i18n setup #51009

Open torleifhalseth opened 1 year ago

torleifhalseth commented 1 year ago

Verify canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:58 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6020
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.6-canary.0
      eslint-config-next: 13.4.4
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Internationalization (i18n), Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue or a replay of the bug

https://github.com/torleifhalseth/my-app

To Reproduce

  1. Create a Nextjs application using the app directory with a page that fetches data using async and await in Server components
  2. Add i18n support to the next config
  3. Deploy to Vercel
  4. Visit the page

Describe the Bug

The page return 404 on Vercel. Locally it works as expectet both when running npm run dev and npm run build + npm run start

Here is the preview of the application reproducing the issue: https://my-app-torleif.vercel.app/ Here is a page using async await to fetch data in server component: https://my-app-torleif.vercel.app/favorite

Here is the deployment data from Vercel: Screenshot 2023-06-13 at 15 09 26

Screenshot from the error in Vercel logs:

Screenshot 2023-06-09 at 09 03 17

This PR with the related issues looks very related, but the problem persists when deployed to Vercel for some reason. https://github.com/vercel/next.js/pull/47429

Expected Behavior

Expect the page to return the page with data.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

Vercel

torleifhalseth commented 1 year ago

Would be nice to append these labels:

area: Routing Routing (next/router, next/navigation, next/link) area: I18n Internationalzation (i18n) kind: bug

bennettstuart commented 1 year ago

Thanks for finding this, I had no idea this is what was causing my 404s! For now, I'm commenting out our i18n config in our next config to allow dynamic app routes in the meantime.

torleifhalseth commented 1 year ago

After further debugging this, I found that it returns 404 for all pages using server components with async fetch when configuring our app with i18n.

I updated my example with a page called /favorite that is fetching the data for my favorite (Pikachu).

I would really like to keep the i18n support, and I guess this is supposed to work.

Any ideas on how we can solve this without removing the i18n configuration?

torleifhalseth commented 1 year ago

So I did some more research and in the app-router-migration you can find this information:

"The locale, locales, defaultLocales, domainLocales values have been removed because built-in i18n Next.js features are no longer necessary in the app directory. Learn more about i18n."

I followed this example to test the new setup without these old values(config) and it works as expected. Example: https://my-8gq8d30ui-torleif.vercel.app/nb/favorite

The challenge I have now is using this new setup together with the old configuration to support i18n in both pages and app. Any idea if that is possible? Screenshot 2023-06-13 at 15 43 37

torleifhalseth commented 1 year ago

In the /pages context, I am using getStaticPaths to predefine some dynamic pages. After removing the old i18n config this now fails when building: Error: Invalid locale returned from getStaticPaths for /pokemon/[slug], the locale nb is not specified in next.config.js. Is there any way around this challenge except by moving the product pages to the app structure? 🤔

torleifhalseth commented 1 year ago

We ended up removing the i18n configuration that we used in the context of our pages when fetching data using getStaticProps and defining the paths using getStaticPaths. For now, we just hardcode our default locale and query that data / define paths.

I guess it would be nice to support the combination to make the transition to using App Router as smooth as possible 🤷‍♂️

Anyhow this is the end of my monologue 😂

JuaniSilva commented 1 year ago

I have the same issue, I was getting crazy. Im just going to comment the intl for the momment

jeremymarc commented 1 year ago

same issue here... can't comment i18n configuration as our old pages rely on it.

phil-tutti commented 1 year ago

Hello, thank you for reporting this.

This issue currently also blocks us from partially migrating some of our routes to the new app router. So we either to a all or nothing approach, which is not really something we're confident doing (as it will also take a long time). It'd be great if someone could share some details if this is going to be fixed.

phil-tutti commented 1 year ago

I'd like to add that this does not only happen if you have a page with data fetching. I created a reproduction repository, where the routing is broken when the app route exposes a GET function. https://github.com/phil-tutti/nextjs-routing-repro

  1. run yarn dev
  2. go to http://localhost:3000/de/broken
  3. see a 404 page being returned

If you remove i18n prop from next.config.js and redo the same steps above, everything works as expected.

Edit: The bug is also present in next.js 14

Silon commented 11 months ago

This issue still occur in 14.0.3

koborg commented 8 months ago

Do we have any progress here? We experience same issue on 14.1.1 as well. In our case we cannot make a complete migration to router, as we have a very big product and it will take sufficient amount of time and resource. It will be great if we have an option to migrate gradually and keep i18n config. We even plan to fork the library and perform "temporary fix" if possible. Any good ideas are appreciated...

Alex-Rudoy commented 6 months ago

Apparently I still have this error, year after...