e650047d4b
The server and client compilers have different external dependency resolution logic. The server prefers CJS while the client prefers ESM by default. This causes an issue when that dependency is a client component entry. We get the module reference during RSC render, which is the CJS file path. And that module reference can't be located in the flight manifest as it was generated via the client compiler (has the ESM path). This PR changes the entry creation logic to use resolved requests, instead of the raw requests. So both SSR and client will have the same resolved import paths to ensure the module reference consistency. ## Bug - [ ] Related issues linked using `fixes #number` - [x] Integration tests added - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md) ## Documentation / Examples - [ ] Make sure the linting passes by running `pnpm build && pnpm lint` - [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md) |
||
|---|---|---|
| .. | ||
| page.js | ||