-
Notifications
You must be signed in to change notification settings - Fork 27.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NEXT-659] Next.js 13 is broken for custom server with multiple zones #45852
Comments
I have posted a bounty for this issue here: https://app.bountysource.com/issues/116848892-next-js-13-is-broken-for-custom-server-with-multiple-zones |
@sirrodgepodge Based on the doc https://nextjs.org/docs/advanced-features/multi-zones#how-to-merge-zones and the example https://github.com/vercel/next.js/tree/canary/examples/with-zones For development, you need to run each zones separately. For deployement, you have to configure Vercel or NGinx to redirect the request to there respective zones. (https://blog.logrocket.com/exploring-zones-in-next-js/) |
As in they need to be run in separate processes? Why is this? Intuitively I don't see why the code I have wouldn't work (it used to lol). I get that that's how the example is done but what I'm doing seems like it would be a perfectly valid alternative |
I haven't seen that the backend was in fact a reverse proxy with Express... When testing your example with Next v12,
|
hmm next I think this is an unrelated error that just has to do with webpack loader config |
doubled the bounty on this one: |
I'm looking into this right now and it is a pretty interesting bug (or feature, if it is an intended side effect). There is certainly some global state that acts weird with multiple NextServers. Not sure if this is all intended or not, but either way there's definitely some inconsistency in how things operate. |
Hi,
i'm in the process of uploading the fix which seems at least for me to
solve the issue.
Il giorno dom 26 feb 2023 alle ore 00:21 Jason Mandel <
***@***.***> ha scritto:
… Would love to see this resolved! I wanted to write a cli that spins up a
next app in the background for a project i'm working on and seems like it's
blocked on this
—
Reply to this email directly, view it on GitHub
<#45852 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWGJD4CLRRII65VPXEBUA23WZKHZHANCNFSM6AAAAAAU2JQLYA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
*Vittorio Parrella*
Software Developer
***@***.***
Naples, Italy
|
Also for the changes required to the demo app: sirrodgepodge/busted-zones#1 |
holy bejeesus, thank you, looking |
thank you @parvit - this looks great, it is still super unintuitive that one must change the app component names tbh, sounds like maybe that's a webpack issue? But ofc it doesn't affect a normal application with two components named the same. regardless, thank you so much for figuring this one out, as soon as it's merged into a non-canary version of Next.js will release the bounty |
Yes i agree, its most probably an optimization of webpack based on the name
of the exported functions.
But i'm not familiar at all with the internals of it to say exactly where
it is failing.
Il Lun 27 Feb 2023, 19:10 Roger Beaman ***@***.***> ha
scritto:
… thank you @parvit <https://github.com/parvit> - this looks great, it is
still super unintuitive that one must change the app names tbh, sounds like
maybe that's a webpack issue? But ofc it doesn't affect a normal app with
two components named the same.
—
Reply to this email directly, view it on GitHub
<#45852 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWGJD4AT3DWJSIT2L4NEPH3WZTUXVANCNFSM6AAAAAAU2JQLYA>
.
You are receiving this because you were mentioned.Message ID: <vercel/next
.***@***.***>
|
This ensures we don't keep `entries` and `invalidator` in module scope directly and nest it under a key specific to each compilation so multiple `next` instances in the same process don't override one and another. ## Bug - [x] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) Closes: #46432 Fixes: #45852
Hi, this should now be patched in |
@ijjk I've tested on my end from a fresh checkout and i can confirm that only updating the version to |
@parvit - to be clear, you're saying you don't need to make any of your other changes (e.g. changing the app component names), you just need to update to this version, correct? It's a decent amount of work to update our actual app to confirm so I just want to be sure. |
@sirrodgepodge Yes i just updated the next version in all the package.json files and it worked. |
@parvit thank you!! confirmed - bounty released :) |
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Verify canary release
Provide environment information
Previously all worked on Next version
12.1.5
Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
https://github.com/sirrodgepodge/busted-zones
To Reproduce
Following the instructions in the README, start by running
Mystery #1
First visit
See that
./hotel-guest/pages/_app.tsx
gets rendered ("Guest App" and the top left), but the component renders a 404, even though./hotel-guest/pages/index.tsx
is defined.Mystery #2
Even more perplexing... now visit
See that
./hotel-host/pages/_app.tsx
gets rendered ("Host App" and the top left), but the component, instead of./hotel-host/pages/index.tsx
renders the content of./hotel-guest/pages/index.tsx
!!!For mystery #1, I have no idea, for mystery #2, I can only conclude that there's a global next.js pages cache of some sort (independent of next.js app instances).
Describe the Bug
I've upgraded to Next 13 and I'm seeing some insane behavior.
First there's an issue with just rendering standard pages where it's a 404.
Second, is as if there is a global next.js cache that is being referenced across multiple next app instances (I.e. "zones") because when visiting the second app instance, the second
_app.tsx
is rendered and the firstindex.tsx
is rendered.Expected Behavior
These apps should render independently.
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
NEXT-659
The text was updated successfully, but these errors were encountered: