### What?
* move some shared runtime logic to turbopack
* use relative imports from internal code when possible
* move react-refresh logic to turbopack
* move benchmark code logic to turobpack
see https://github.com/vercel/turbo/pull/4553
### Why?
We want to have benchmarking again for turbopack PRs
We want to have a standalone turbopack cli (eventually)
We want to avoid duplicating the runtime code
### How?
refactoring, moving code
This accomplishes 2 things:
1. binds the turbopack dev server to the IPv6 unspecified address
2. initializes our router with the same hostname/port of the turobpack
server
The first matches the behavior of the Node.js dev server. The IPv6
unspecified address is similar to IPv4's `0.0.0.0` address, allowing us
to accept connection from anywhere. Importantly, it _also_ allows
accepting IPv4 connections, making this address truly universal.
The second means the `request` parameter to any middleware will have the
correct origin, and the request's URL can be used to craft fetch
requests to API endpoints. `new URL(req.url).origin` will be the origin
of the turbopack dev server.
Fixes https://github.com/vercel/turbo/issues/4456
Fixes WEB-855
### What?
Fix missing `,` in loader tree code.
also adds `unsupported` as category of implicit metadata issue
### Why?
The loader tree to JS generated invalid code when there there where two
non-page files in a directory.
fixes WEB-861
Next.js adds a `Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch`
to app routes for both rendering and flight requests. Without this, the
browser can mistakenly serve the flight request to the app render, and
vice versa.
This only adds `Vary: RSC` for the moment, I'm not sure what the others
are used for. We also don't add a `Cache-Control: max-age=0` header, but
I'm not sure if that's necessary either.
Fixes NEXT-657
fix#45595
### What?
avoid including the error twice in the output
### Why?
`.context()` already keeps the previous error, no need to include in the
error message again
### What?
enables the benchmark tests from turbopack again
### Why?
It tests common scenarios like HMR
fixes WEB-792
---------
Co-authored-by: Alex Kirszenberg <alex.kirszenberg@vercel.com>
This is the Next.js side of https://github.com/vercel/turbo/pull/4397
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
When the devs have a parse/module-eval error in their Page/App module, Turbopack's rendering process will fail to connect the IPC. This is because the entrypoint statically imports the dev module. If either fails, then we'll never reach the code to set up the IPC. This leads to a "timeout while receiving message from process" timeout error after 30s, instead of receiving an exact message/stack detailing the dev's error.
By wrapping the import code in a deferred dynamic-import closure, we're able to connect the IPC first, then evaluate the dev code. This wrapping style is a little awkward, but it's necessary with the way to inject virtual modules into our graph.
Fixes WEB-850
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
-->
### What?
This PR implements a feature for the turbpack to support (partial)
transform configuration inherited from ts/jsconfigs, notably for the
legacy decorators and jsx runtimes.
### Why?
### How?
- Closes WEB-667
### What?
Refactors the resolving logic for the `app` loader tree. This PR ensures
it's used to create entrypoints in turbopack. Next up is integrating it
into the webpack build too.
These changes also ensure that parallel routes resolving is applied,
which previously wasn't supported in turbopack.
### Why?
Part of the effort to deduplicate critical logic between
turbopack/webpack in Next.js, this will help land features in
turbopack/webpack at the same time.
### How?
Quite a few changes. @sokra helped a ton on this PR. `app_structure.rs`
was changed to the new resolving logic so most of the logic is there.
Additionally we added support for calling the same function in two ways
from Node.js: `turbo.entrypoints.get` and `turbo.entrypoints.getStream`.
`get` can be used by `next build` to get the full list of
entrypoints/loadertrees once. `getStream` has watching built-in and
calls a callback function with the new list anytime a file is added that
would change the loadertree.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
see also https://github.com/vercel/turbo/pull/4415
We need a full process polyfill to fix some edge cases
Also disables SourceMap for edge chunks, since they are not used
### Why?
Some packages do weird things, e. g.
```
var isBrowser = process.title === 'browser'
```
Turbopack starts up the router process with all ENV values, but the edge
function definition didn't list any `env` keys for the function
invocation. So, middleware couldn't access any ENV values.
Turbopack doesn't currently have a way to determine what ENV keys are
actually used by the source program, so I'm just passing everything
defined. I'm not sure if that's an issue during dev (I could see it
being one for the build process, but that doesn't matter for this case).
Fixes#47766
Fixes WEB-831
Fixes WEB-834
