This uses styled issue titles and details introduced in
vercel/turbo#6535, which also moves "Module not found" messaging to the
title field for those issues.
Closes PACK-2013
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: Leah <github.leah@hrmny.sh>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
Various fixes in handling of externals in node.js
* add extensions to builtin externals to allow node.js ESM to work
* improve the auto-externals logic to detect more edge cases
* prepare for `esmExternals` support, but that's blocked by client
manifest missing the async flag
* currently only `esmExternals: false` is supported
### Why?
### Turbopack Changes
* https://github.com/vercel/turbo/pull/6531 <!-- Leah - fix(turbopack):
postcss should be applied to `@import`ed CSS files -->
* https://github.com/vercel/turbo/pull/6530 <!-- Tobias Koppers - fix
node.js externals -->
---------
Co-authored-by: Leah <github.leah@hrmny.sh>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
We are experimenting with `lightningcss`. This is about replacing
`swc_css` with `lightningcss` in turbopack, and the main reason for this
is to reduce the maintenance burden.
But when I tried, it introduced several regressions, so I'm putting it
behind an experimental flag.
You can enable `lightningcss` mode for **turbopack** by adding a flag to
the next config file.
```js
/**
* @type {import('next').NextConfig}
*/
const nextConfig = {
experimental: {
useLightningcss: true,
},
}
module.exports = nextConfig
```
Note that this is only for turbopack because we were not using `swc_css`
for non-turbopack mode of next.js
x-ref:
https://vercel.slack.com/archives/C03EWR7LGEN/p1700025496732229?thread_ts=1700019629.866549&cid=C03EWR7LGEN
### Why?
We should avoid regressions.
### How?
---
turbopack PR: https://github.com/vercel/turbo/pull/6456
Closes PACK-1966
---------
Co-authored-by: Leah <github.leah@hrmny.sh>
This updates the rust toolchain to 2023-11-16 and:
- Removes now-unnecessary `#![feature(async_fn_in_trait)]`
- Applies auto-fixable lint fixes
- Uses `Cargo.toml` new `lint` section instead of command line rustc flags
Test Plan: Tested with updated turbo in a create-next-app
Closes PACK-1979
Co-authored-by: OJ Kwon <1210596+kwonoj@users.noreply.github.com>
Requires vercel/turbo#6388
This uses the structure implemented in vercel/turbo#6388 to support formatted text when reporting. Right now only the `Line` and basic `String` cases are handled.
### What?
Update SWC crates. This PR fixes a regression of `swc_core`.
The important PR: https://github.com/swc-project/swc/pull/8153
### Why?
There was a regression in `swc_core`.
### How?
- Fixes#56408
Closes WEB-1811
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This:
- Uses `isServer` to use the appropriate Turbopack `FileSystem` when
creating `FileSystemPath`s
- Properly uri decodes path segments originating from `file://` uris
- Correctly reads chunks starting at the project path instead of the
root path
Closes WEB-1815
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
The asset context is a better place to store the layer, because it's
affected by transitions unlike the chunking context
This PR also removes a bunch of unused code
### Why?
See https://github.com/vercel/turbo/pull/6237 for the rationale
Also needs to wait for that PR to be merged
Closes NEXT-1814
#### Turbopack Changes
* https://github.com/vercel/turbo/pull/6237 <!-- Leah - chore: move
layer from chunking context to asset context -->
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
This implements support for properly tracing sourcemaps when presenting
error stacks to the user. It also adds code frames when possible.
Closes WEB-1764
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Closes WEB-1702
This PR implements initial support for the `next/dynamic` in Turbopack,
more specifically resolving some hydration errors and other components
boot up cases.
Previously, turbopack had partial next/dynamic support via its own mode
(https://github.com/vercel/next.js/pull/56389/files#diff-e1af4f79cb88a73f819a25443d15ed4b1ffabcbb879256caa59b751fad46d7c4L68),
which does a transform against `next/dynamic` wrapped import to embed
dynamically resolvable chunk ids like
(ad42b610c2/packages/next-swc/crates/next-transform-dynamic/tests/fixture/wrapped-import/output-turbo-dev-server.js).
However, since next.js relies on static path to the chunks to the
dynamic import and passing those ids in between client-server to ensure
component load (and avoid hydration errors), it doesn't work out of the
box. This PR changes turbopack's behavior to closely mimic what current
next.js's webpack plugin does, by
1. Traverse the module graph, find out `dynamic(import())`
2. Generate chunks for those imports, creates a partial LoadableManifest
per each imports
3. Merge partial manifest into a single `react-loadable-manifest.json`
4. For the id, use static (Webpack mode) instead of dynamic so we can
embed it in `react-loadable-manifest` as well as next.js can use it to
pass it between server-client context.
I left a small comment to the implementation
(https://github.com/vercel/next.js/pull/56389/files#diff-bf12ed2c69d0bc89a06884779da4ae44967eb8becada031dea12bedef28e2622R155)
for the lifecycle of this feature in case to fix further.
This makes to pass most of the basic next-dynamic related integration
tests, except if the import have webpack specific features like
ad42b610c2/test/development/basic/next-dynamic/pages/dynamic/multiple-modules.js (L5).
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What?
Step 3 in our chunking refactors extracts ChunkItem::as_chunk into a new ChunkType trait. This new trait isn't useful yet, but will eventually allow us to collect ChunkItems of a similar type into a lists, and perform chunking over all similar items at once.
### Why?
In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
https://github.com/vercel/turbo/pull/6123
Re: https://github.com/vercel/next.js/pull/56504
Closes WEB-1724
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
### What?
The second step in our chunking refactoring, this removes our use of Module::as_chunk and Module::as_root_chunk. Instead, the only way to generate a chunk is directly from a root ChunkItem.
### Why?
In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
https://github.com/vercel/turbo/pull/6120
Re: https://github.com/vercel/next.js/pull/56467
Closes WEB-1721
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
### What?
This change moves a few methods around.
Module::as_chunk is moved to ChunkItem::as_chunk as temporary intermediate state.
EcmascriptPlaceable::as_chunk_item is moved to ChunkableModule::as_chunk_item. This generalizes the concept of converting a Module into a ChunkItem
### Why?
This is the first step of refactoring the chunking. In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
see https://github.com/vercel/turbo/pull/6104
Closes WEB-1715
Co-authored-by: Justin Ridgewell <112982+jridgewell@users.noreply.github.com>
### What?
This implements Server Actions inside the new Turbopack next-api bundles.
### How?
Server Actions requires:
1. A `.next/server/server-reference-manifest.json` manifest describing what loader module to import to invoke a server action
2. A "loader" entry point that then imports server actions from our internal chunk items
3. Importing the bundled `react-experimental` module instead of regular `react`
4. A little 🪄 pixie dust
5. A small change in the magic comment generated in modules that export server actions
I had to change the magic `__next_internal_action_entry_do_not_use__` comment generated by the server actions transformer. When I traverse the module graph to find all exported actions _after chunking_ has been performed, we no longer have access to the original file name needed to generate the server action's id hash. Adding the filename to comment allows me to recover this without overcomplicating our output pipeline.
Closes WEB-1279
Depends on https://github.com/vercel/turbo/pull/5705
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
### What?
Deduplicates our env var injection between the JS and rust side
Closes WEB-937
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Depends on vercel/turbo#6036
This constructs a general asset prefix (depending on if basePath and/or assetPrefix is defined), and sets it on Next's and Turbopack's chunking context.
Test Plan: Use a `create-next-app` with corresponding Next.js PR and basePath and assetPrefix specified.
Tested:
- Browser (async) chunk loading
- Static asset loading on server and browser
Closes WEB-1666
We've rearchitected Next.js+Turbopack so Turbopack does not run
reimplement pieces of Next.js in its devserver. This:
- Removes the `next-dev` binary, which is no longer reachable through
`next --turbo`.
- Removes its test suite, as much of it is tested (and often more
thoroughly) by the Next.js test suite
- Removes its benchmark suite, which should be covered by
`Turbopack-bench` by
https://github.com/vercel/turbo/tree/main/crates/turbopack-bench
Test Plan: CI
Closes WEB-1652
This:
- Updates to the latest api change for `StdError` in `error_generic_member_access` rust-lang/rust#99301
- Updates `pathfinder_simd` for compatiblity
Closes WEB-1636
### What?
I made `styled-jsx` configurable. It uses `swc_css` by default, and with
`useLigntningcss: true`, it uses it.
https://github.com/swc-project/plugins/pull/207
### Why?
### How?
Closes NEXT-
Fixes #
Closes WEB-1532
### What?
Strip the relative path prefix (`_next/`) when generating the `PageLoaderAsset`. This is necessary because the page loader will internally use `__turbopack_load__`, which prepends the prefix back onto the path.
### Why?
Without this, we'd try loading `_next/_next/path/to/file.js`, because we'd prepend the prefix onto a path that already contains it.
### How?
When generating the page loader asset, we "proxy" the `OutputAsset` onto a path which has the prefix removed.
~~Depends on https://github.com/vercel/turbo/pull/5717~~
Closes WEB-1377
This implements a MVP of HMR. HMR works similarly as in turbopack-dev-server, but instead of going through the router to retrieve output assets, output assets are eagerly stored into a global hash map, and retrieved directly from there (see `VersionedContentMap`).
This will require some more glue on the Next.js side in order to handle:
* RSC headers;
* handling Turbopack subscriptiob HMR events from the Next.js WS server, proxying them to `hmr_events`, and sending back the stream of updates.
There's currently no way to evict deleted output assets, nor to communicate these events to the client. @sokra mentioned the `VersionedContentMap` could store a list of assets per entrypoint, instead of having a top-level flat map.
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
### What?
closes WEB-1301. To collect some information inside of rust binary, embed it as build-time constant. It supersedes existing target triple embedding as well.
This implements app pages and routes for the Nexturbo API.
## Turbopack updates
* https://github.com/vercel/turbo/pull/5527 <!-- Alex Kirszenberg -
AdjacencyMap::reverse_topological (+ fixes) -->
This is the Next.js side of https://github.com/vercel/turbo/pull/4587, which makes changes to Turbo Engine to allow expressing value cells as `Vc<Type>` instead of `TypeVc`, leveraging the type system to bring a slew of other improvements to writing Turbo Engine code.
## Turbopack updates
* https://github.com/vercel/turbo/pull/4587
### What?
Creates a NAPI api for Next.rs to be used in Next.js
### Why?
### How?
Co-authored-by: Alex Kirszenberg <1621758+alexkirsz@users.noreply.github.com>
This PR adds proof-of-concept support for the App Router to `next build
--experimental-turbo`.
It introduces a new way to generate Next.js manifests in Turbopack.
Currently, in dev, we pass proxy objects in lieu of manifests, and rely
on the entries to know which chunks they need loaded on the client.
However, this can't work for builds because it requires control over
Next.js rendering, which is not compatible with a Next->Turbo approach.
We would need to modify Next.js to support these "lazy" entries. So for
now, we add well-known assets (`NextDynamicAsset`,
`NextServerComponentAsset`, `NextClientReferenceAsset`, etc.) to the
graph, which will get picked up when walking it during asset processing.
This lets us collect all possible entries before chunking.
This two-step process (collecting all entries, then chunking them) is
also a good first step towards production chunking.
## Turbopack updates
* https://github.com/vercel/turbo/pull/5494 <!-- Tobias Koppers - add
reporting of console messages -->
* https://github.com/vercel/turbo/pull/5448 <!-- Alex Kirszenberg -
Misc. changes to support App Router build -->
### What?
Update SWC crates to `v0.79.13`.
### Why?
- Explicit resource management proposal is now fully implemented, although it's behind a parser flag because it's stage 3
- Some bugs of `swcMinify` are fixed.
### How?
Closes WEB-1272
## Turbopack updates
* https://github.com/vercel/turbo/pull/5475
Co-authored-by: Alex Kirszenberg <1621758+alexkirsz@users.noreply.github.com>
Depends on https://github.com/vercel/turbo/pull/5398 (and downstack) on
the Turbo side.
This PR makes it so the output path of Node.js entry chunks for pages is
determined solely from the pathname. This isn't actually necessary for
pages, but it makes for easier debugging anyway. See the Turbo PR for
more details.
This also changes the page structure so it also works if there is no
`pages` directory. In this case, we still want to use pages' default
_app, _document, and _error pages, even with existing app routes. So an
empty page structure should still have an effect.
## Turbopack updates
* https://github.com/vercel/turbo/pull/5415 <!-- Will Binns-Smith -
Turbopack: Execution tests in node.js -->
* https://github.com/vercel/turbo/pull/5461 <!-- Tobias Koppers - use a
lock to ensure atomic invalidation from file changes -->
* https://github.com/vercel/turbo/pull/5398 <!-- Alex Kirszenberg -
Configure the path of the Node.js entry chunk -->
* https://github.com/vercel/turbo/pull/5469 <!-- Tobias Koppers - allow
hmr tests to correctly detect hmr event -->
This contains the original POC for `next build --turbo`. The implementation is _just enough_ to get pages building, and doesn't support the app router yet.
I'll write more details here on the implementation and what the next steps are next week.
Necessary changes on the Turbo side: https://github.com/vercel/turbo/pull/4998
### What?
* enable turbopack tests in new CI
* split pre-build step into native and JS builds to allow to start
native tests faster
* update swc_core to sync with turbo
* update turbopack
### Why?
Running our test suite is still important as long we don't have the full
integration test suite enabled.
### Turbopack updates
* https://github.com/vercel/turbo/pull/5215 <!-- OJ Kwon - ci(workflow):
upload benchmark results to datadog -->
* https://github.com/vercel/turbo/pull/5239 <!-- OJ Kwon -
fix(swc_plugin): use shared runtime -->
* https://github.com/vercel/turbo/pull/3090 <!-- CHEN Yuan - Docs: prior
to run testcases, add guides to install dependencies for testcases. -->
* https://github.com/vercel/turbo/pull/5264 <!-- Tobias Koppers - update
test runner -->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
With vercel/turbo#5156, we'll be able to install our the locally built `next` package. Before, we'd test the tip-of-branch `next-dev` binary against the last cut `next` canary, which causes headaches when we make breaking changes.
With this PR, we'll now test tip-of-branch `next-dev` binary against a tip-of-branch `next` package, and breaking changes can be properly benched.
Fixes WEB-1133
### What?
create internal modules via `context.process` with
`ReferenceType::Internal`
### Why?
We need this for future refactoring where we want to the internal
modules with transitions.
### Turbopack Changes
* https://github.com/vercel/turbo/pull/5095 <!-- Tobias Koppers - allow
to create internal modules via AssetContext -->
* https://github.com/vercel/turbo/pull/5104 <!-- Alex Kirszenberg -
Stable chunk list ident -->
* https://github.com/vercel/turbo/pull/5106 <!-- Tobias Koppers -
followup fix -->
---------
Co-authored-by: Alex Kirszenberg <alex.kirszenberg@vercel.com>
This PR is extracted from https://github.com/vercel/next.js/pull/49942
and mostly contains changes necessary after the Turbopack PR adding the
Node.js production runtime https://github.com/vercel/turbo/pull/4998,
without any of the actual Next Build stuff, in order to be able to merge
both quickly.
* ChunkData moved from tp-dev to tp-core, the ES-serializable part moved
to tp-ecmascript;
* all runtime types moved to tp-ecmascript-runtime
This also upgrades Turbopack to turbopack-230526.2:
* https://github.com/vercel/turbo/pull/5102 <!-- Donny/강동윤 - refactor:
Fix binary bloat caused by `ValueDebugFormat` impl -->
* https://github.com/vercel/turbo/pull/4998 <!-- Alex Kirszenberg -
Node.js production runtime POC -->
### 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>
### 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
`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>
<!-- 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>
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?
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 -->
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
### 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.
<!-- 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.
