Frontend loads admin panel bundle when next/link is included into root layout or home page

[Arctomachine]

Describe the Bug

If next/link component is used in (frontend)/layout or (frontend)/page, admin panel bundle is loaded on / route.
Introduced in beta 128, probably by #8364

Workaround: move (payload)/layout into (payload)/admin/layout

Link to the code that reproduces this issue

https://github.com/Arctomachine/payload-127

Reproduction Steps

1. Install packages (beta 127)
2. Build, start. Check network tab for loaded js files
3. Migrate to beta 128 by guide in feat!: on demand rsc #8364
4. Build, start. Check network tab for loaded js (should load at least 3 new big files)
   

Which area(s) are affected? (Select all that apply)

Not sure, area: core, area: ui

Environment Info

Binaries:
  Node: 20.17.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  payload: 3.7.0
  next: 15.1.0
  @payloadcms/db-mongodb: 3.7.0
  @payloadcms/email-nodemailer: 3.7.0
  @payloadcms/graphql: 3.7.0
  @payloadcms/next/utilities: 3.7.0
  @payloadcms/payload-cloud: 3.7.0
  @payloadcms/plugin-seo: 3.7.0
  @payloadcms/richtext-lexical: 3.7.0
  @payloadcms/richtext-slate: 3.7.0
  @payloadcms/translations: 3.7.0
  @payloadcms/ui/shared: 3.7.0
  react: 19.0.0
  react-dom: 19.0.0
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
  Available memory (MB): 32720
  Available CPU cores: 12

[jmikrut]

Hey @Arctomachine — I have successfully reproduced this. You're right in that moving the layout.tsx file to the /admin folder fixes the issue as well. Very strange.

I do think that this is a problem with Next.js though. We should open an issue there. It seems like next/link is indeed causing the entirety of the layout from Payload to be included in the JS downloaded by the browser, even though the First load JS metric when building looks correct.

If you are up for it, and you want to create a Next.js issue, that would be great! Otherwise I will get to it shortly.

[Arctomachine]

Sure, I can do it. But what should I put in there? I am not aware of what changes were made between betas 127 and 128 to pinpoint exact issue. The best I can do right now is to describe same thing I did here and attach same repository

[jmikrut]

I don't think it's really anything to do with Payload. It would be best to have a minimal reproduction with the following:

- /app
  - /(group-1)
    - layout.tsx
    - page.tsx (with next/link usage)
  - /(group-2)
    - layout.tsx with some big dependency (in our case, payload, but doesnt need to be)
    - /nested-route
      - /[[...slug]]
        - page.tsx 

I would imagine this would be enough to showcase the issue, that group-1 loads the dependencies from the group-2 layout. I know the Next.js team likes to have as minimal of a reproduction as necessary, so including Payload in its entirety would be overkill I think.

Does that make sense?

[Arctomachine]

Sure, I will see if I can make this reproduction work, and then will open issue there

[Arctomachine]

Turns out I cannot reproduce it with just that.
But also if it was just that, then it would not break between 127 and 128 since next package keeps same version and general folder structure remains same. What changes is only something inside payload package and contents of /admin layout file.

My guess is using server function in /admin layout from 128 is somehow related.

[jmikrut]

OK - good find. Do you have a repo started that I can play around with? Can you try and add a server function into the /(group-2)/layout.tsx file to see if that is indeed it? I think you're right there. Just need to narrow it down to that. It would still be a Next.js issue I think.

[Arctomachine]

Basically their reproduction template with payload installed into it reproduces this issue. But it comes with all payload things like database connection and etc, no idea how to remove irrelevant parts. I can upload repository in its current state