This change allows the Turbopack's node router to serve
`_next/static/development/_devMiddlewareManifest.json` file, which is
just the matchers for middleware routes. This is usually handled by the
node dev server anyways, but we were filtering out the route so that
Turbopack could handle it.
But, Turbopack doesn't implement the route matching logic at all, it's
all handled by our node router. So Turbopack can't know what the
middleware matchers are. Having the router just handle this like the
normal dev server is both easy and efficient (I don't want to spin up
_another_ node instance just to transform the matchers into the expected
format).
Fixes WEB-979
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
This reverts commit 6ebc725fe6 / #50247.
### Why?
#49972 is reverted due to bugs, and I'm retrying it.
### How?
Closes WEB-1072
Closes WEB-1097
Closes NEXT-1156 (as it's reopened by the revert PR)
fix#48469
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Implement a CJS optimizer for next-swc
### Why?
x-ref: https://vercel.slack.com/archives/C02HY34AKME/p1684341093462309
Assuming most CJS files are transpiled from ESM, we can mimic
tree-shaking using an AST transform.
### How?
Closes WEB-1072
Fixes#48469
fix NEXT-1156
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
* allow to apply existing pipeline
* change webpack loader key to glob for more flexibility
* add test cases
* add special error message when using the old config syntax
Old config:
```js
experimental: {
turbo: {
loaders: {
".mdx": ["mdx-loader"]
}
}
}
```
New config
``` js
experimental: {
turbo: {
rules: {
// key is a glob now
// normal syntax will treat the result as ecmascript code
"*.mdx": ["mdx-loader"],
// glob allows more advanced matching
"./images/**/*.png": {
loaders: ["image-optimize-loader"],
// result of loader will be handled in other steps
// under the same name/path (here .png)
// This will use the existing .png pipeline (static asset)
// It might also use other rules matching .png.
as: "*"
},
"*.generate-image.js": {
loaders: ["image-generation-loader"],
// It also possible to pass this under a different name
// into the pipeline. Here it will treat the result as png image
as: "*.png"
}
}
}
}
```
### Why?
More flexibility and allowing to use the builtin module handling over
non-js types.
fixes WEB-1009
### Turbopack changes
* https://github.com/vercel/turbo/pull/4955 <!-- OJ Kwon -
refactor(turbopack-ecmascript): deprecate enable_emotion, enable_styled*
-->
* https://github.com/vercel/turbo/pull/4880 <!-- Tobias Koppers -
refactor webpack loader execution -->
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
<!-- 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
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
WEB-1086.
This PR flips the way running next.js integration test with Turbopack,
instead of using allowlist to run selectively enabled test now uses
denylists. The immediate effect is now any new test being added (as a
new file) will be executed with Turbopack by default, and should be
manually excluded if it fails.
Still, the number of tests we run remains same.
This adds the `node` condition, so that importing a node module that
uses `exports` with a `node` specified will prioritize that file. Eg,
[uuid](https://github.com/uuidjs/uuid/blob/4de23a60/package.json#L25-L31)'s
`package.json` will now resolve to the `./dist/esm-node/index.js` in our
SSR builds, instead of the default `./dist/esm-browser/index.js`
Fixes WEB-1051
### What?
adds `NEXT_TURBOPACK_TRACING` env var to enable tracing. Writes into `.next/trace.log`
There are 4 presets:
* `NEXT_TURBOPACK_TRACING=overview` gives a overview of requests and modules processed.
* `NEXT_TURBOPACK_TRACING=next` above plus details for next.js
* `NEXT_TURBOPACK_TRACING=turbopack` above plus details for turbopack
* `NEXT_TURBOPACK_TRACING=turbo-tasks` above plus details for turbo-tasks
Published release builds will only allow `overview` to work, since all detailed instrumentation is statically disabled.
see https://github.com/vercel/turbo/pull/4966 for more details
### Why?
get more insight into build times
### Turbopack changes
* https://github.com/vercel/turbo/pull/4995
* https://github.com/vercel/turbo/pull/5049
* https://github.com/vercel/turbo/pull/5053
* https://github.com/vercel/turbo/pull/4966
<!-- 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
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
WEB-654.
This PR attempts to implement initial sass support in turbopack, via
sass-loadder. Internally it points to sass-loader compiled in next.js
(`next/dist/sass-loader..`) with next.config.js's option. Still it is
not a complete implementation, for example sourceMap is not supported by
upstream turbopack.
PR requires turbopack side changes as well.
For static member expressions like `foo.bar`, we currently treat it as one whole Ident `foo.bar` and pass it over the `$$bound` array as one value. That causes a problem where the Ident inside the function body needs to be converted, because it can no longer access to `foo`.
Closes#49985.
fix NEXT-1206
<!-- 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 #
-->
This PR adjusts manifests for the next.js test with Turbopack, as I
found upstream test keep changing and need to sync its latests state
into the manifest.
Manifest is now .js file contains 2 arrays, one for the enabled, and
others for the disabled. Disabled doesn't mean it's always failing
though.
`getSortedRoutes` is used in the `BuildManifestPlugin`, which I'm in the
process of porting to Next.js Turbo as part of Next Build. As such, I
ported it to Rust using GPT-4 (with manual review over the code).
The resulting code is not particularly idiomatic nor optimized Rust
code, but it passes all tests (similarly converted) and should be more
than fast enough for now.
In the process of porting, GPT-4 made some "suggestions" (read: it
automatically and silently changed parts of the code) which actually fix
some formatting issues with errors:
https://github.com/vercel/next.js/pull/48298
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
This introduces a `NextMode` enum that controls which mode Next.js Turbo
is currently running in:
* `NextMode::Development`: `next dev`
* `NextMode::Build`: `next build`
Requires https://github.com/vercel/turbo/pull/4972
This also update Turbopack to `turbopack-230517.2` with the following
changes:
* https://github.com/vercel/turbo/pull/4972 <!-- Alex Kirszenberg -
Configure React development flag, inherit NODE_ENV from execution
context -->
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Now that the beta docs have been merged into stable with the release of
13.4, this updates all links as some paths have changed due to
redirects.
---------
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Because of the flexibility of export declarations, we can't know the
exact export type of exported values so we should allow all of them.
Especially when we already have runtime checks.
fix#49378
fix NEXT-1137
### What?
Disable `tracing/release_max_level_info` for non-published release
builds. I modified CI script to strip out logging for published
binaries.
### Why?
x-ref: https://vercel.slack.com/archives/C03EWR7LGEN/p1683621374204959
It's required to print logging for turbopack.
### How?
Closes WEB-1032
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
<!-- 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
### Why?
### How?
Closes NEXT-
Fixes #
-->
#### What
Part 1 for WEB-848.
This PR implements initial path to enable relay compiler option in
Turbopack. PR is based on approach WEB-955, that passing custom plugin
transform itself instead of trying to pass down configuration into
turbopack. In result, this PR requires counterpart turbopack PR at
https://github.com/vercel/turbo/pull/4721.
PR also refactors next-shared's transform bit, as we have grown number
of custom transforms.
Unfortunately there are some runtime errors with this transforms, so it
is not possible to use relay actually yet. WEB-956 tracks this.
(https://github.com/swc-project/plugins/pull/179)
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This PR extends `invalid_server_react_dom_apis` with
`experimental_useOptimistic` and `experimental_useFormStatus` to create
early compile-time errors.
### What?
Fixes serving images that are referenced by JS files inside the `/app`
directory.
### Why?
### How?
The `NextImageContentSource` attempts to fetch the image out of it's
inner content source, and before we were only providing it with the
`/public` and `/pages` directory's respective sources.
Re: https://vercel.slack.com/archives/C046HAU4H7F/p1683220799917649
### What?
RSC also needs a different next/dynamic on client side
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Reorganize the test cases a bit by separating server/client graphs. And
make sure that using `'use server'` inside a Client Component will
result in a compilation error.
Currently we are always use an array for the `.$$bound` field of an action even if it's empty. This PR updates the transform to generate `null` in that case so we can do further optimizations. Note that `[]` and `null` are slightly different here similar to `f.bind`.
A simple test case to ensure `cookies()` is usable inside App Routes,
based on a prior bug report.
Closes WEB-627
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What?
removes the
```
event - startup 3.643ms
```
message
### Why?
no useful information in this message since it's just too fast
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This makes sure that we are treating a module as in the server layer, if
it's under the client layer but with file-level `"use server"`. Also
makes sure we're catching errors like having both `"use server"` and
`"use client"` directives presented.
See https://github.com/vercel/turbo/pull/4776
This adds support for:
* Default and custom global app 404 pages (`app/not-found`).
* Segment-level 404 pages (`app/segment/not-found`).
This also updates Turbopack:
* https://github.com/vercel/turbo/pull/4787 <!-- Tobias Koppers -
Bugfixes for free var and binding replacement -->
* https://github.com/vercel/turbo/pull/4789 <!-- Alex Kirszenberg -
Print a warning when importing Sass files -->
* https://github.com/vercel/turbo/pull/4776 <!-- Alex Kirszenberg -
Leave pathname formatting up to the caller -->
* https://github.com/vercel/turbo/pull/4790 <!-- Tobias Koppers - remove
inital compilation message by default -->
## TODO:
- [ ] ~~The dev overlay shows up when `notFound()` is called, it should
be hidden~~ (moved to WEB-980)
- [ ] ~~Navigating to the global 404 page doesn't work~~ (this is a bug
in Next.js, see NEXT-963)
- [x] Tests.
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What?
allows to change blur mode for structured images
also improve performance for static metadata images in app dir by avoiding computing blur placeholder
### Why?
we might want to change the blur mode (in dicussion)
### How?
adds an enum to control the mode
### What?
- closes WEB-800
This PR mimics fallback google font behavior for the turbopack from https://github.com/vercel/next.js/pull/47428, replaces fallback to capsize and adjust read logics.
This PR does three things:
- Vendors the package `react-server-dom-webpack@experimental` as
`react-server-dom-webpack-experimental` similar to React and React DOM
- Upgrades all vendored React packages
- Re-lands the `experimentalReact` flag to switch between `@next` and
`@experimental` channels of React for app dir.
Fix NEXT-926.
### What?
fixes handling of GlobalError interop
adds a test case for client component bug
### Why?
app dir client component interop is broken
### Turbopack changes
* https://github.com/vercel/turbo/pull/4597 <!-- Tobias Koppers - add
rspack to our benchmark suite -->
* https://github.com/vercel/turbo/pull/4761 <!-- Tobias Koppers - Do not
use interop logic on proxy modules -->
### What?
add a test case
### Why?
Some packages expect the default export of a commonjs module to be the whole exports object when importing from ESM.
turbo PR: https://github.com/vercel/turbo/pull/4738
### What?
add .svg to the list of images that that return metadata
### Why?
.svg files should also return width and height
### How?
see https://github.com/vercel/turbo/pull/4741
We bind to an IPv6 unspecified address (`::`), which makes the old message say "started server on :::3000", and that's kinda ugly. The new message will say "[::]:3000".
This PR updates the way we preload fonts. Previously we tracked which
fonts we needed to preload for each layer and rendered a `<link
rel="preload" href="..." as="font" />` tag for each preloadable font.
This unfortunately gets blocked by data fetching and we want to be able
to hint these preloads as soon as possible. Now that React support Float
methods in RSC we can use `ReactDOM.preload(..., { as: "font" })` to
implement this functionality
This PR makes the following changes
1. expose a `preloadFont` method through the RSC graph
2. expose a `preconnect` metho through the RSC graph
3. refactor the preloads generation to use `preloadFont` instead of
rendering a preload link
4. If there are no fonts to preload but fonts are being used in CSS then
a `preconnect` asset origin is called instead of rendering a preconnect
link
5. instead of emitting a data attribute per font preload indicating
whether the project is using size-adjust we now emit a single global
meta tag. In the future we may get more granular about which fonts are
being size adjusted. In the meantime the current hueristic is to add
`-s` to the filename so it can still be inferred.
In the process of completing this work I discovered there were some bugs
in how the preconnect logic was originally implemented. Previously it
was possible to get multiple preconnects per render. Additionally the
preconnect href was always `"/"` which is not correct if you are hosting
your fonts at a CDN. The refactor fixed both of these issues
I want to do a larger refactor of the asset loading logic in App-Render
but I'll save that for a couple weeks from now
Additionally, the serialized output of preloads now omits the word
anonymous when using crossorigin so tests were updated to reflect
`crossorigin=""`
Additionally, tests were updated to no longer look for the size-adjust
data attribute on preloads
Additionally, There is a note about leaving a `{null}` render in place
to avoid a conflict with how the router models lazy trees. I'll follow
up with a PR addressing this
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
<!-- 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
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
This PR changes turbopack's appDir source lookup to honor existing
behavior to ignore `_` started path. With this changes, turbopack able
to pass test
`test/e2e/app-dir/underscore-ignore-app-paths/underscore-ignore-app-paths.test.ts`,
fixes WEB-844.
Internally it simply amends two parts, first if given path starts with
_, do not add those into entrypoints to it will not be served. If path
starts with `%5F` instead, replacing path to _ so it can be served.
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What?
We previously ran all route handlers with the edge runtime, which means
you can't use built in node.js modules
With this PR, the runtime can be selected as documented in the next.js
docs
Fixes WEB-873
Depends on https://github.com/vercel/turbo/pull/4491
This adds support for the new `output: 'export'` configuration, and
propagates the value through to our Node.js rendering code to render.
Unfortunately, we don't support page-level configs at the moment, so we
can't set a `export const config = { dynamic: 'force-dynamic' }` and
test that the export value is being received (I've manually verified it,
though).
Fixes WEB-842
Mostly mirrors the changed made in
https://github.com/facebook/react/pull/26632 to our SWC transform. The
implementation difference is that the AST transformer only adds a
general purpose wrapper call `createServerReference(id)` from an aliased
import, so we can easily change the underlying function in the bundler.
This change only affects the client layer (when `self.config.is_server
=== false`).
Needs to be landed after another React upgrade:
https://github.com/vercel/next.js/pull/48697.
cc @sebmarkbage.
This PR implements preloading of CSS from RSC.
1. The underlying Flight protocol was extended in
https://github.com/facebook/react/pull/26502 to allow sending hints from
RSC to SSR and Client runtimes. React was updated to include these
changes.
2. We now call `ReactDOM.preload()` for each stylesheet used in a
layout/page layer
There are a few implementation details to take note of
1. we were previously using the `.browser` variant of a few React
packages. This was a holdover from when there was just browser and node
and we wanted to use the browser variant b/c we wanted the same code to
work in edge/node runtimes. React now publishes a `.edge` variant which
is like `.browser` but expects to be server only. This is necessary to
get the opt-in for `AsyncLocalStorage`.
2. Even with the above change, AsyncLocalStorage was not patched on the
global scope until after React was loaded. I moved this into a module
which is loaded first
3. The component passed to RSC's `renderToReadableStream` is not
actually part of the RSC module graph. If I tried to call
`ReactDOM.preload()` inside that function or any other function defined
inside `app-render.tsx` file it would actually see the wrong instance of
`react-dom`. I added a new export on the RSC top level export which
exposes a `preloadStyle(...)` function which just delegates to
`ReactDOM.preload(...)`. This makes the preload run in the right module
graph
~There are a couple of bugs in React that this work uncovered that I
will upstream. We may want to delay merging until they are addressed.
I'll update this comment when that is complete.~
1. ~React, during SSR, can emit a preload for a style twice in some
circumstances because late discovered stylesheets don't consider whether
a preload has already been flushed when preparing to reveal a boundary
they are within~
2. ~React, during RSC updates on the client, can preload a style that is
already in the document because it currently only looks for existing
preload links and does not consider if there is a stylesheet link with
the same href.~
~both of these issues will not break functionality, they just make the
network tab look at bit more noisy. We would expect network deduping to
prevent multiple actual loads~
The above React bugs were fixed and included now in the React update in
this PR
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
* support local static metadata files; opengraph-image, twitter-image,
favicon, manifest, icon, apple-icon
* support global static metadata files: robots.txt, sitemap.xml,
favicon.ico
* dynamic metadata is not yet implemented, but yields a warning
It's implemented a bit different compared to the webpack version.
All images will use the usual image machinery, so they are emitted to
output directory, content hashed and the url is shared with the same
import import in the app.
### Why?
Unsupported, and we want to have that.
### How?
see also https://github.com/vercel/turbo/pull/4692
fixes WEB-524
### What?
WEB-953.
This PR moves, bubbles up unsupported package warning from turbopack to next-core using resolve plugin. Featurewise it behaves same, however removes turbopack aware specific next.js package (`@vercel/og`) internally.
### What?
Fix snapshots that were no longer fulfilling the original purpose after
prettier had its way.
The `.prettierignore` also had the old `target/` directory (prior to the
`Cargo.toml` move in #48198) so running `pnpm prettier-fix` formatted
files in the `target/` directory
### What?
Seems I accidentally included the app root when I initially added it,
but apps never have a page loader, so they should be excluded
I also cleaned up the manifest a bit, and it now perfectly matches the
one in next.js
Fixes WEB-926
<!-- 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
### How?
Closes NEXT-
Fixes #
-->
### What?
This PR changes to the `root` of the cargo workspace to the root of repo
itself, allows next-swc and other rust codebase can use repo root as
workspace root.
### Why?
Currently cargo manifest for the next-swc is not placed under the root
of the repo, which makes invocation to the tool requires to change cwd /
or set cwd. Similarly needs to open editor to the root of the cargo
manifest separately to able to utilize language server kicks in. Moving
manifest to the root consolidates those, so can invoke either cli / or
editor to the same root of the repo.
<!-- 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
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
Attempt to close WEB-920.
This PR implements next.config.js's `modularizeImports` option to
turbopack. It tries to read next.config.js, and then apply transforms as
same as `next-swc` does. Internally it interops betwen next.config.js's
PackageConfig to swc's PackageConfigs, as it doesn't have necessary
attributes for the Vcs / deserialization.
We decided in https://github.com/vercel/next.js/pull/48308 that we won't
use `turbo` when packing packages for tests.
This PR removes all code associated with that effort. The whole thing
fas behind a flag, so it shouldn't affect anything.
fix NEXT-1025
<!-- 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
### How?
Closes NEXT-
Fixes #
-->
### What?
This PR enforces turbopack uses `automatic` jsx runtime.
- closes WEB-901.
### Why?
If you set `ts|jsconfig`'s `jsx` to any custom value, you'll encounter
next.js message
```
The following mandatory changes were made to your tsconfig.json:
- jsx was set to preserve (next.js implements its own optimized jsx transform)
```
Then internally transform sets jsx to use automatic runtime instead. In
case of turbopack, its transform pass is embedded so instead of setting
it to preserve falls back to automatic by default. PR doesn't handle
validations / or emitting user friendly messages yet, just enforce
runtime config regardless of how user sets it.
There maybe some additional followups to mimic exact transform existing
next.js does.
---------
Co-authored-by: Maia Teegarden <dev@padmaia.rocks>
### What?
* fix app dir chunking
* fix app dir 404s
* improve app dir performance
* rerender shadowportal on errors to re-add nextjs-portal to avoid empty
page
* inject polyfills before user code
* fix manifest generation
see also https://github.com/vercel/turbo/pull/4488
### Why?
App dir was very slow and lead to 404 errors
### How?
add included metadata to chunks to allow deduplicate chunk loads at
runtime
### Description
The next.js router will proxy requests if there's a rewrite with an
external URL, for POST requests this currently leads to an `ECONNRESET`,
because the client request has no body.
Fixes WEB-824
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### 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
Paired with https://github.com/vercel/turbo/pull/4329, this implements
streaming responses for App and API renders. This is accomplished by
sending an initial `headers` message (carrying the status code and
headers list), N `body-chunk` messages of bytes, and a final `body-end`
message to signal completion.
Once sent to Turbopack, these chunk messages will be streamed out of the
node rendering process directly into the HTTP server's response.
Closes WEB-27
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
