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>
