Previously `next-swc` had relay transform inline, but it makes
maintenance harder. So this PR patches next-swc to use relay plugin from
`swc-project/plugins` repository.
Closes WEB-782
Fixes#47239
fix NEXT-883 ([link](https://linear.app/vercel/issue/NEXT-883))
Revert some code in #47379 and finalize HOC support. We should require
the HOC to return a "use server" function, so there's no need to compile
the function call specially now.
To make that wrapping logic work, we need to allow passing a server
reference to another server reference. This usually happens in the
function closure in the HOC case, but ideally it's also allowed to
directly pass it as an argument. This requires adding React server DOM's
`encodeReply` and `decodeReply` and other corresponding changes,
including adding `busboy` (can probably be vendored?) as we need to
parse the multipart body now.
fix NEXT-808 ([link](https://linear.app/vercel/issue/NEXT-808))
([link](https://linear.app/vercel/issue/NEXT-808))
This PR addresses two bugs:
- The parameters of arrow functions were not being tracked in `closure_idents` due to not being visited via `visit_mut_param`. They are stored as `Vec<Pat>` instead so we need to handle these as a special case.
- The rest parameter could not be transformed into `...r = closure[1]`, so we changed that case to `r = closure.slice(1)`.
fix NEXT-874 ([link](https://linear.app/vercel/issue/NEXT-874))
Fun! This depends on https://github.com/vercel/turbo/pull/4251 to
implement streamed Node evaluations, giving us the ability to support
streamed middleware responses.
This is just the first step to supporting RSC streaming in Turbopack. I
chose to start with this because it requires all the same base logic,
and I understand the full router->middleware->HTTP server code path, so
it's a lot easier to work on.
Fixes WEB-738
When using a "use server" module, only exporting async functions is
permitted. However, since we cannot perform static analysis on all
exported value types (e.g., `export const foo = condition ? A : B`), we
have added a runtime ensure function to validate that these are indeed
valid functions.
By implementing this, we can prevent any strange errors like "Can't
access $$typeof of undefined or null" that may arise when exporting
`undefined` or `null` from a server entry. Moreover, this measure helps
avoid any potential mistakes that may occur.
fix NEXT-865 ([link](https://linear.app/vercel/issue/NEXT-865))
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This PR is largely preparation work for next/font/local by
compartmentalizing and modularizing existing pieces of next/font/google.
It:
* Renames the top level directory to `next_font`
* Places next/font/google-specific code into `next_font/google`
* Extracts common structures and methods into top-level
`font_fallback.rs`, `stylesheet.rs`, `util.rs`, etc.
* Updates visibility of structures and functions to use `pub(super)`
within `next/font/google`
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
The old `test_generator::test_resources` could only find resources relative to the project root, and not relative to the test file. Because of the new nextpack directory structure, this causes all kinds of headaches between running in nextpack and running in turbo (`next.js/packages/next-swc` vs `nextpack/next.js/packages/next-swc`).
When calling the server (via `callServer`), we concat all closure values
(`$$bound`) and arguments of the function call into one array on the
client. Hence on the server, we will have to compile the function
differently to support that.
With this change, the compiled function will have a `$$with_bound` flag
to indicate that if it accepts closure values. If so, the only argument
passed will be an array like `[...bound_values, ...fn_args]`, and we
compile the function parameters to `(closure, arg1 = closure[N], arg2 =
closure[N + 1], ...)` where `N` is the number of the closure
identifiers. This way we can still fill these arguments by only pass an
"bound + args" array. If it doesn't accept closure values, it will be
directly called with `...fn_args` so no compilation change needed.
The reason that we use `arg1 = closure[N]` is that this can support
complex patterns in parameters such as `f(closure, {a} = closure[1], [b]
= closure[2])`.
fix NEXT-487 ([link](https://linear.app/vercel/issue/NEXT-487))
* Rename client reference plugins from `Flight*` to `ClientReference*`
* Rename `serverComponentManifest` to `clientReferenceManifest`
* Group the key/value in client reference manifest
* Update turbopack crates
fix NEXT-827 ([link](https://linear.app/vercel/issue/NEXT-827))
This aligns use of the next/font transform across the workspace under a
single crate, now called `next-transform-font`.
### What?
Improve the UX of the error overlay
### Why?
* error overlay doesn't reopen when closed, but new error appear
* error overlay shows non-actionable warnings in node_modules
* error overlay shows unrelevant errors in node_modules
### How?
* low priority for errors in node_modules
* hide node_modules warnings
* open error overlay on new error
* Also updated the files I touched to the next.js prettier format
fixes WEB-712
fixes WEB-713
fixes WEB-714
fixes WEB-727
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
This PR makes sure that we are not appending statements after the function or arrow expression, if they're actions. Instead we put all them in a `ParenExpr` so the entire thing can be defined inline.
fix NEXT-813 ([link](https://linear.app/vercel/issue/NEXT-813))
In short, this PR adds a 3rd layer to the server compiler. This extra
layer is for marking the modules when re-entering the server layer from
a client component. It is almost identical to the existing server layer
and it should have all the same bundling and runtime behaviors, but it's
still special because it's not allowed to enter the client layer again
from there.
Because of that, we create the extra entry for that new layer when the
client layer compilation finishes in the `finishModules` phase. The new
entry is handled normally as it's in the server layer. But the original
module in the client layer will be compiled specially as special no-op
exports, and will then be connected via the `callServer` wrapper.
fix NEXT-809 ([link](https://linear.app/vercel/issue/NEXT-809)).
Builds on https://github.com/vercel/turbo/pull/4202 to implement custom Next.js Transformers in Turbopack.
This is the final piece to moving the `next-*` crates to Next. While we've _technically_ moved everything, Turbopack didn't support running custom transformers. So we're actually stuck on the last version we cut before deleting the next crates, running the transformers that exist in the turbopack repo. With the new support, we're almost back to the tip of main branch (there's still some snafu with `swc_core` upgrading that I'm working on).
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
### What?
enables the next-dev-tests crate integration tests from trubopack
### Why?
to unblock the move PR we temporarily disabled the tests
### How?
Fix the new location and fix the expect dependency
Fixes WEB-708
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
It will be crucial to detect these common problems and abort compilation, because it's intended to be using a server boundary but these problems might cause it ending up in the client.
Fixes NEXT-762.
This PR does two major changes:
1. Make sure both pages renderer and app renderer return `RenderResult`,
no more `null`. This was achieved with a new `null` type in the
constructor `new RenderResult(null)`, and a `.isNull()` method.
2. Remove all mutations of the `renderOpts` object inside renderers. To
pass extra information out, they need to be attached to the
`RenderResult` now. This also requires 1) to be done.
These changes are the initial steps to the isolated rendering worker
architecture. Besides those there're also some type improvements.
Fixes NEXT-807.
---------
Update workspace cargo deps
Update cargo deps to point to local workspace
Ignore too-many-arguments warnings
Fix clippy errors
Update pnpm workspaces
exclude integration tests from unit tests CI
rust-analyzer settings
add rust flags and env vars
This is almost a rewrite of the transform to simply some logic. For a `"use server"` file we now simply annotate every exported identifier and will later do runtime checks. This is because that we can't statically know the source of exported values.
This rewrite also makes it possible to annotate anonymous arrow functions.
Thanks to @kdy1 for some of the suggestions here.
Closes NEXT-708, closes NEXT-421.
### Description
Keeps track of available modules when importing new chunk groups. Omits
assets that are already available in the parent chunk group(s) when
determining assets to be included in chunks.
### Testing Instructions
Dynamic imports should not include modules that are already in the
parent chunks
<!--
When the below is checked (default) our PR bot will automatically
assign labels to your PR based on the content to help the team
organize and review it faster.
-->
- [x] Auto label
fixes WEB-599
### Description
Another attempt to close WEB-659.
The crux is same as previous PR, but attempt to change the location
where it read config / bubble down the config values to the actual
transform stage. Mainly, `enable_typescript_transform` is now accepting
an option instead of boolean flag to down to
`EcmaInputTransform::Typescript`, and `get_*_module_context()` reads the
config value as needed.
This PR adds basic support for default export of an async arrow
function:
```js
export default async (a, b) => { console.log(a, b) }
```
In upcoming PRs I'll refactor named export handling and inlined
declarations.
### Description
Add more details to introspection and make it more robust to errors
during introspection
### Testing Instructions
go to http://localhost:3000/__turbopack__/
This diff:
* introduces the `VersionedContentMerger` trait, which allows for
merging the updates of versioned contents within the same chunk group;
* implements this for `EcmascriptChunkContent`/`EcmascriptChunkUpdate`,
turning them into
`EcmascriptMergedChunkContent`/`EcmascriptMergedChunkUpdate`;
* creates a new `ChunkList` asset which is capable of merging chunk
updates of chunks within the same chunk group, and create such an asset
for dynamic chunks (through manifest/loader_item.rs) and chunk group
files assets.
This fixes a bunch of edge cases related to HMR:
* HMR of dynamic imports now works;
* Chunks getting added/deleted/renamed now also works with HMR, since
we're listening to updates at the chunk group level;
* CSS chunks get reloaded in the right order, with respect for
precedence.
There are still known edge cases with HMR:
* CSS chunks added through HMR are not inserted at the right position to
respect precedence (WEB-652).
* Update aggregation is disabled because we don't want a critical issue
to stop all HMR (WEB-582) . This would be fixed by applying aggregated
updates when dismissing the error modal, but there are some edge cases
with this too (e.g. what happens when an HMR update also causes an error
on top of an existing error).
Add support for cases like:
```js
const foo = async function () {}
export default foo
const bar = async function() {}
export { bar }
```
Also fix a bug where nested async function declarations are mistakenly
counted as actions.
Fixes NEXT-800.
This removes the duplicated (and possibly mismatching) font data file in
favor of loading the copy bundled with next, using `load_next_json`
introduced in vercel/turbo#4086. It also removes the associated workflow and
generation script.
Similar to #46888, this PR adds support for the case:
```js
async function foo () {}
export default foo
```
...where you export an ident as a default export expression.
Closes NEXT-770
~Should be landed after #46881.~
### Description
This PR mirrors some related manifest changes in Next.js:
https://github.com/vercel/next.js/pull/46881.
### Testing Instructions
<!--
Give a quick description of steps to test your changes.
-->
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
This:
* Generates and uses definitions for fallback system fonts to use in
place of user fonts, or as they are loading.
* Reads the font metrics file from the `next` package directly relative
to the user's app.
* Fixes a bug where `adjust_font_fallback` defaulted to `false` instead
of `true`.
* Begins to refactor next/font code to be more modular in anticipation
of `next/font/local` support.
* Changes `handle_resolve_error` to take an origin `FileSystemPathVc`
instead of a `ResolveOriginVc` as this is all it used, and a resolve
origin isn't always available.
This PR adds the support for unnamed default export expression support
`export default async function () {}` in a "use server" entry, with
corresponding test.
Also fixed an existing bug that the default exported action's name
should be aligned with the export name, which is `"default"`.
Closes NEXT-769.
### Description
Cargo always uses default features for workspace dependencies, so we
can't use that here. See also comment.
### Testing Instructions
```
$ cargo tree -p next-binding -i openssl --target x86_64-unknown-linux-gnu -e features
error: package ID specification `openssl` did not match any packages
```
### Description
The isolation is unnecessary and we can reuse files when we share
directories
### Testing Instructions
Open multiple pages without client-side navigation in multiple tabs
concurrently.
Since the default export syntax is not `fnDecl` but `fnExpr` I added two new methods to abstract out all the transform logic and made both `visit_mut_fn_decl` and `visit_mut_fn_expr` use that.
Next step is to support default exports without an ident (`export default async function () {}`).
Fixes NEXT-768.
## 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)
### Description
Ensures `target` is optional to match vercel/turbo#46801 which removes the option.
<!--
✍️ Write a short summary of your work.
If necessary, include relevant screenshots.
-->
### Testing Instructions
<!--
Give a quick description of steps to test your changes.
-->
This:
* Adds a compile-time feature, `__internal_nextjs_integration_test`,
which is set when building Turbopack for the Next.js integration test
suite.
* When built with `__internal_nextjs_integration_test`, expects the
environment variable `NEXT_FONT_GOOGLE_MOCKED_RESPONSES` to be set with
an absolute path to a JavaScript file exporting a mapping of urls to
stylesheet text. This is used in place of making real requests to Google
Fonts.
* Addresses some small bugs in next/font/google to bring the
implementation in line with the urls generated by Next.js without
Turbopack.
* Changes classnames generated by next/font to use 6 character hashes,
bringing it in alignment with Next.js without Turbopack.
Test Plan:
* Adjusted existing unit tests
* In Next.js, `node run-tests.js -c 1 test/e2e/next-font/index.test.ts`
### Description
<!--
✍️ Write a short summary of your work.
If necessary, include relevant screenshots.
-->
### Testing Instructions
<!--
Give a quick description of steps to test your changes.
-->
<!--
When the below is checked (default) our PR bot will automatically
assign labels to your PR based on the content to help the team
organize and review it faster.
-->
- [x] Auto label
<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order 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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Failing test for #35734.
This implements webpack loader context api for `emitError` and
`emitWarning`, each of which emit Turbopack issues at the appropriate
error level. As with webpack’s implementation, `emitError` does _not_
cause builds to fail [0].
This uses next-dev issue snapshots (vercel/turbo#3774) to test that issues are
emitted.
[0] https://webpack.js.org/api/loaders/#thisemiterror
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
### Description
* use completions to signal additional invalidations for evaluation
* avoid adding these modules as runtime entries, since that will
unnecessarily code generate, bundle and execute these modules
* gets rid of the watch_files_hack
### Testing Instructions
* change postcss.config, next.config.js, etc. -> changes will be
reflected by the app and process restarts
### Description
Follow-up changes for https://github.com/vercel/turbo/pull/4018
<!--
When the below is checked (default) our PR bot will automatically
assign labels to your PR based on the content to help the team
organize and review it faster.
-->
- [x] Auto label
### Description
* get rid of attached filesystem for our embedded modules
* get rid of import "." in favor of inner assets
depends on vercel/turbo#3999
### Testing Instructions
existing tests
<!--
When the below is checked (default) our PR bot will automatically
assign labels to your PR based on the content to help the team
organize and review it faster.
-->
[X] Auto label
* add Asset::ident() as unique identifier of an Asset
* add ChunkItem::ident() instead of ChunkItem::to_string()
(ValueToString)
* base `chunk_path` on AssetIdent instead of path only
Motivation:
We want to get rid of the `import "."` in favor of inner assets. When
doing this we no longer need to place virtual assets below the actual
file path and they can stay in their original path. But placing virtual
assets below the actual asset also made the `Asset::path` unique, which
would no longer be the case after using inner assets. Some parts of the
code base relied on `Asset::path` being unique (e. g. module ids and
chunk paths). But actually we never guaranteed that to be unique.
After this PR `Asset::ident` is intended to be unique and allow to carry
more information than only the path:
* Query string (`module?query`)
* Fragment (`module#fragment`)
* Asset (additional wrapped assets by key value pairs)
* Modifiers (additional transformations applied on the module, e. g.
`chunks`, `client chunks`)
* In future: Part (select a subpart of the module, e. g. only export
abc, or the module evaluation, or some internal part)
Partially resolves WEB-671.
There are some test cases use `data-nextjs-dialog-header` to lookup its
inner text to verify error output. Due to differences of error overlay
layout between turbopack / next-dev, those 2 have different inner texts.
PR applies a workaround, by introducing new data tag
`data-nextjs-turbo-dialog-body`. Next.js upstream will need following
update to utilize this tag in its test suites.
This accomplishes 2 things:
- Moves the creation of the edge info onto the Next.js side
- Extracts the middleware's `export const config = {}`, so that we can know what matchers are needed before invoking the edge function definition.
After this, an update to the Next.js side will enable middleware.
Fixes WEB-623
This:
* Adds issue snapshot support to next-dev-tests. This will allow us to
assert that certain issues are raised in tests that require next-dev.
* Extracts common snapshot code into a new crates,
`turbopack-test-utils`, which is shared between snapshot tests and
next-dev-tests.
* Implements an issue reporter that emits issues in a channel to the the
integration test code, where they are snapshotted.
* Fixes an issue where next-dev tests that were not Next.js apps would
emit non-fatal issues for a missing `pages/` directory.
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
Closes#43732.
We currently detect if a module is CJS by look through all string tokens to see if any contains `"__esModule"`. That causes `console.log('__esModule')` being detected as CJS accidentally. This PR changes to detect these cases:
- `module.exports`
- `exports.__esModule` (e.g. `exports.__esModule = true`)
- `Object.defineProperty(exports, "__esModule", ...)`
Although this solution isn't perfect, it's much more reliable that the current one already.
Note that this also fixes a bug for `@vercel/og` that although `satori`'s ESM module is imported, it still has the `__esModule` string inside, introduced by bundling its vendors.
## 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)
This:
* Addresses feedback from https://github.com/vercel/turbo/pull/3862
* Exempts VirtualAssets from webpack loaders. This addresses a bug where
next-hydrate.tsx could not be read.
* Adds `ModuleRuleCondition::ResourceIsVirtualAsset` to filter these
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
We currently use the `NEXT_RSC_ERR_INVALID_API` error code for metadata API conflicts which is wrong. The format should be `NEXT_RSC_ERR_INVALID_API: foo` and then the formatter transforms it into `foo isn't supported in app/`.
This PR adds a new `NEXT_RSC_ERR_CONFLICT_METADATA_EXPORT` error code and improves the message. Closes#46406.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] 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)
<!--
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:
-->
This improves the ambiguous error seen when exporting `metadata` or
`generateMetadata` from a component marked with the `"use client";`
directive.
Example output from tests (`pnpm test-dev
test/development/acceptance-app/rsc-build-errors.test`)
```console
File path:
app/client-with-errors/metadata-export/page.js
console.log
browser log: ./app/client-with-errors/metadata-export/page.js
ReactServerComponentsError:
You are attempting to export "generateMetadata" from a component marked with "use client", which is disallowed. Either remove the export, or the "use client" directive. Read more: https://beta.nextjs.org/docs/api-reference/metadata
,-[6:1]
6 |
7 | // export const metadata = { title: 'client-metadata' }
8 |
9 | export async function generateMetadata() { return { title: 'client-metadata' } }
: ^^^^^^^^^^^^^^^^
`----
File path:
app/client-with-errors/metadata-export/page.js
```
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] 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
- [x] 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)
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This will automatically apply `babel-loader` to Next.js apps that
include a babel configuration file alongside `next.config.js`. It
requires the app to provide `babel-loader` itself.
Test Plan: Added an integration test.
This implements a new `ContentSourceProcessor` trait and
`WrappedContentSource` struct that allows our `ContentSource`s to
register some processor to transform the eventual `ContentSourceContent`
that an inner `ContentSource` returns. Yah, it's a bit of a mouthful
with lots of very similar sounding names.
Essentially, the old `SourceMapContentSource` and
`NextSourceMapTraceContentSource` wrapped some inner `ContentSource`,
and would request content from them, and process that content into a
source map JSON or trace JSON. But, they didn't implement the `NeedData`
response, so it only supported very primitive inner content sources.
This PR extracts that knowledge into a single `WrappedContentSource`,
which will recursively wrap every `ContentSourceResult` until we land on
a fully resolved `ContentSourceResult::Result`. At that point, it hands
off the work to a `WrappedGetContentSource`, which performs the
processing on whatever content is returned by the inner
`GetContentSourceContent`. If you can't tell yet, I'm making the
description intentionally verbose to highlight just how similar our
struct/trait names are.
Fixes WEB-614
This switches the `chunk_content_internal` function from a sequential
BFS to a parallel BFS (+ reverse topological sort at the end).
I expected this to make some difference in performance, as traversing
references in parallel can lead to better CPU usage (see vercel/turbo#3771), but in
practice our benchmarks show no significant difference.
Real apps might be a different story, but I didn't notice any particular
performance improvement on vercel.com either.
This implementation is not perfect (we're making more calls to
`get_children` than strictly necessary), but I think it's enough to
measure a potential performance improvement.
Marking this as a draft for now as it's more complicated than the
current implementation and there's no clear win to adopting this.
We now store react errors in the error overlay (hydration errors) and if
the error overlay receives the "build ok" message after that it will
hard reload the page to recover
define process.env.NODE_ENV to development for next-dev
define and set `process.turbopack`
---------
Co-authored-by: Will Binns-Smith <wbinnssmith@gmail.com>
We need to invalidate router node.js process when routes change for correctness
In future we can pass the routes list to next.js instead of only invalidating @jridgewell
We also need the separated structure for next build @alexkirsz
The benefit of this depends on
https://github.com/vercel/next.js/pull/45962, but it remains compatible
with apps including `loader-runner`.
This first attempts to require `loader-runner` from the app's installed
version of Next.js, falling back to requiring the package directly. We
should probably eventually remove this fallback once all compatible
versions of Next.js include the precompiled version, as that has a more
predictable version of the package.
Test Plan: Linked a local copy of Next.js including
https://github.com/vercel/next.js/pull/45962 to an app without
`loader-runner` that uses loaders and verified loaders ran.
Before the static evaluation didn't consider the fact that objects and arrays can be mutated. So we can't just assume for sure that they have certain properties/items. Instead we add an unknown mutation alternative to handle that.
This avoids `if(obj.prop)` to be replaced with `if(true)` when prop is initialized with true. It might be modified in future.
This PR fixes the bug where a client boundary (`"use client"`) is defined in a module (`"type": "module"`). Currently Next.js throws this error:
```
error - Error: Cannot find module 'private-next-rsc-mod-ref-proxy'
```
...that will be resolved with this PR.
The only limitation after this fix is, you can't have `export *` under a client boundary in a module. Added a error message for that.
NEXT-595
## 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)
* Use next-swc to detect invalid metadata exports
* In client components page under app dir, metadata exports are not
available
* In server components page under app dir, metadata and gM exports can
be exported together
Move sync metadata / async metadata typing resolving test to UT
Closes NEXT-368
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Another small cleanup stemming from the the `basePath` PR. Makes the
introspection ordering consistent, which is a nice usability win.
Co-authored-by: Alex Kirszenberg <1621758+alexkirsz@users.noreply.github.com>
This fixes 2 bugs that I've found:
1. If the `middleware.ts` file doesn't exist, then we get an unhelpful `unable to resolve relative "."` error during `next-edge` transition processing
- This is fixed by not processing the `VirtualAssetVc` with the edge transition
2. If you're using an older Next version, then the router doesn't have a `type` field
- Because the `type` field is empty, we hit neither the `rewrite` nor `none` cases and fall through to the middleware case, returning an empty response with no body.
- This is fixed by treating `{ url: string, headers: … }` as `{ type: 'rewrite', url: string, headers: … }`
This updates our Next.js router, passing the `edgeInfo` manifest generated from the `middleware.js` file (or any other configured page extension).
Fixes WEB-277
Fixes WEB-370
extracted from https://github.com/vercel/turbo/pull/3670
Refactoring to allow to pass more compile time info next to the environment to modules.
e. g. we want to pass `process.env.NODE_ENV = "development"` in future
Adds support for the CSS module `composes:` rule.
This also fixes a large issue with our chunk ordering and CSS precedence, where the BFS order of our chunks did not match the expected topological ordering.
This restores issue reporters, addressing a bug that prevented turbo-trace from completing. This moves `ConsoleUiVc::new` into an async block to prevent it from stalling.
Test Plan: Verify `cargo run --bin node-file-trace -- print path/to/my/app` no longer stalls.
This gets rid of this warning when using a client component as page:
```
warning - [analyze] [project-with-next]/src/app/client/page.jsx unexpected export *
export * used with module [project-with-next]/src/app/client/page.jsx which has no exports
Typescript only: Did you want to export only types with `export type { ... } from "..."`?
```
* fix export * warning for client pages
* Detect `__turbopack_export_value__` as CJS style exports
* fix `__turbopack_cjs__` name
* flag turbopackHelper in client proxy
I changed the return type of the Next.js router in https://github.com/vercel/next.js/pull/45668 to account for cases where the router does and does not find a matching rewrite.
This PR enables `ignoreDynamic` for common js modules which is detected
by `auto_cjs` pass.
Fixes https://github.com/vercel/next.js/issues/40231.
---
I verified that with this change the test reproduction does not fail
with import error.
---------
Both `stringify_str` and `stringify_module_id` are now simply `stringify_js`. We could skip this and go directly to `serde_json`, but this hides the dependency behind turbopack-ecmascript.
For windows it's important that the browser is dropped so that the test can
complete. To do that we need to cancel the spawned task below (which will
drop the browser). For this we are using a JoinSet which cancels all tasks
when dropped.
Big thanks to @jridgewell for helping me out with a number of Rust-isms
with this change.
This expands `handle_issues` and the `NextDevServerBuilder` to accept an
arbitrary `IssueReporter` -- a trait implementing `report_issues` which
receives captured issues to send somewhere.
This replaces using a fixed `ConsoleUi` to send issues to stdout/stderr,
though `ConsoleUi` now implements `IssueReporter` and is the default
implementation of an issue reporter if no other is provided. It also
moves the responsibility of detecting fatal errors out of `ConsoleUi`
and into `handle_issues` itself.
This lays the foundation for alternative reporters, such as a test
reporter to snapshot or assert against issues emitted, or a
newline-delimited JSON reporter for other tools to consume.
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
Dynamic segments should be passed a single string, while catch-all segments should be passed a list of strings.
Furthermore, ctx.params was previously undefined because we weren't passing it forward through the render options.
Run after_resolve with original request
try to resolve original request with node.js options to determine if it can be external
typescript extends need to resolve with bare node.js resolving to avoid custom resolve options
add special pnpm logic to improve externals when pnpm is used
- [x] Depends on https://github.com/vercel/next.js/pull/45776
Turbotrace occupies too many memories while running; this PR makes it
run after the webpack build is finished, it can reduce the memory
hogging by webpack and turbotrace, thus avoiding OOM
The `maxFiles` option in turbotrace is removed because there is
`memoryLimit` option takes over its role.
Close WEB-556
This PR does a little bit more than what it says on the box. Before, we were parsing URL queries and request headers, only to serialize them some other way afterwards. The reason why we were parsing headers and queries is because we sometimes need to filter them. However, we don't need that for router/page SSR/page API. This PR makes it so we avoid parsing on Turbopack's side through `rawHeaders` and `rawQuery`.
This enables HMR updates, even when the update message also contains
critical issues.
There were some inconsistencies with the logic previously, so I'm not
sure whether this fix is fully correct. More on that in PR comments.
Aligning with https://github.com/vercel/next.js/pull/45707, this allows users to import fonts from `next/font/google` as well as `@next/font/google`.
Test Plan: Adjusted tests to use `next/font/google` and added another test to verify `@next/font/google` continues to work.
This combines Turbopack-specific options into a nested object
`experimental.turbopack`, exposing `loaders` and `resolveAlias`
properties.
x-ref:
631b637f42 (r1098123643)
Test Plan: Integration tests for loaders and resolveAlias.
also make source context generation more reusable
This adds a source context snippet of the JSON that failed parsing and
the json path to the error.
```
An error occurred while generating the chunk item [project]/crates/turbopack-tests/tests/snapshot/imports/json/input/invalid.json (json)
at Execution of module_factory failed
at Execution of JsonChunkItem::content failed
at Unable to make a module from invalid JSON: expected `,` or `}` at line 3 column 26
at nested.?
1 | {
2 | "nested": {
| v
3 | "this-is": "invalid" // lint-staged will remove trailing commas, so here's a comment
| ^
4 | }
5 | }
```
Leaves the default implementations of a trait "in place" and implements
the "cross-trait" resolving differently
we get back the normal rust error messages when you don't have every
method implemented 🎉
Following discussion at https://github.com/vercel/next.js/pull/45560,
this renames `experimental.resolveAlias` to
`experimental.turbopackResolveAlias` to make it clear that this option
is only available in Turbopack.
Test Plan: `cargo test -p next-dev-tests`
The node evaluation always renders with `type: "commonjs"` and `require()` calls, so we'll always import the CJS files. But here we're importing the ESM files. That means we have 2 distinct instances of `requestAsyncStorage` in our node instance, and they cannot properly communicate with the other.
Fixes WEB-543
Adds support for `getStaticPaths` returning `{ fallback: false }` by
building out all static paths and checking whether the resolved path is
included in that list.
`buildStaticPaths` requires the `next.config.js` path, as well as other
config options such as locale. I created WEB-546 to track being able to
pass them to the handlers.
Similar to our `try_join` helper this adds a
`try_flat_map_recursive_join` helper, which allows to async expand a
tree structure into all nodes. It will call the async mapper function
concurrently to allow parallelism. It will handle circular and duplicate
references and return all nodes in a determinstic way (breath-first).
Allows to skip unreachable code based on compile-time constant
conditions
e. g.
```
if (!process.turbopack) {
require("will-not-be-processed");
}
```
* add if() and process.turbopack fixes WEB-491
* Removes unreachable code fixes WEB-498
* evaluate some logical operations `&&`, `||`, `??`, `!`
* fix arguments handling fixes WEB-529
* nested effects for function called with closures
* handle closures when array methods are used fixes WEB-538
* evaluates `process.turbopack` fixes WEB-496
Moves all next-dev integration test code into a parent `input/`
directory, like our snapshot tests. This prepares for introducing
`issues` snapshots to next-dev integration tests.
Test Plan: CI
With the addition of the Next.js routing layer at the root of our
content sources, we need the update server to also be able to follow
Next.js rewrites, like the HTTP server.
This requires the following:
* Rewrites need to be able to indicate a source where to "resume" after
rewriting. Otherwise, we would enter an infinite loop of the Next.js
layer rewriting to the Next.js layer.
* The resolving logic from `process_request_with_content_source` needs
to be extracted into its own function, so it may be called both from the
HTTP server (which expects fully resolved `ReadRef`s) and the update
server (which needs a `VersionedContentVc`): this is where
`resolve_source_request` comes in.
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
This adds the turbo-tasks function name as `context` of all fatal errors
propagated from executing or reading turbo-tasks functions.
That should help in debugging fatal errors.
Adds resolve plugins (currently only running `after_resolve`, could add
`resolve` later)
Had to fix `ResolveResult::merge_alternatives` because it merged two
external results into `Unresolvable`
In Turbopack, as a consequence of our lazy compilation model, CSS chunks
can contain duplicate CSS chunk items. This can cause issues with
precedence. Take the following example:
Initial CSS chunk:
```css
/* ... */
/* chunk item A */
h1 {
font-size: 2rem;
}
/* ... */
/* other chunk item */
h1 {
font-size: 4rem;
}
/* ... */
```
Dynamic CSS chunk (loaded after the first page load completes)
```css
/* ... */
/* chunk item A */
h1 {
font-size: 2rem;
}
/* ... */
```
In this example, when the page first loads, the following rule will be
applied:
```css
h1 {
font-size: 4rem;
}
```
But as soon as the dynamic CSS chunk loads, the following rule will be
applied instead:
```css
h1 {
font-size: 2rem;
}
```
However, from the order of rules in the initial load, we know that the
former should still apply.
We can remedy this particular issue by wrapping each CSS chunk item into
its own
[`@layer`](https://developer.mozilla.org/en-US/docs/Web/CSS/@layer)
(thanks @sokra for the idea!). This ensures that when a CSS chunk item
is re-encountered at a later time, it is automatically de-duplicated
thanks to the inherent CSS layering algorithm.
This is not an issue in Next.js as we can't have duplicated CSS chunk
items.
Fixes WEB-525
This allows webpack loaders defined by `experimental.turbopackLoaders` in `next.config.js` to pass serializable options to loaders.
It expands `turbopackLoaders` to accept not just loader names for a given extension, but also `{loader: string, options: Object}`. These options are verified to be serializable and passed to `loader-runner` and exposed as `getOptions()` to the loader.
Test Plan: Added an integration test for basic options. Verified the serializable check by passing `class Foo {}; new Foo()` as an option value and verified the error was displayed.
Fixes WEB-447.
Previously, generated classnames would include literal `/` characters,
which need escaping when generating selectors. While users should still
escape selectors, this avoids it for this case and makes generated code
easier to read. This format is also more aligned with what webpack-based
css modules generates.
This also removes the square character as a separator, since it breaks
words and makes double-clicking for selection more difficult.
Next.js's integration test suite depends on these ids and data attributes to select against items in running test pages. This gets us passing some of those tests.
The previous PR vercel/turbo#3499 only implemented support for `pages` directory.
The `app` directory previously had no validation at all, it's added with
this PR.
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
The new error paths introduced in vercel/turbo#3448 both write their outputs to
`.next/server/pages/`, which conflicts with:
- The main pages source
- Each other
The infinite loop is very fun:
1. We need a `NodeJsPoolVc` to render pages
2. To get a `NodeJsPoolVc`, you need to write your files onto disk
- So a pool is dependent on the contents of those files
3. When we render an error page, we need to write those files to disk
4. The error page shares the same file entrypoint as the main page
source
So, to render an error, we write the entrypoint, which is shared with
main source. This alone is pretty bad, because it will invalidate our
page source's node pool (and kill those processes). But, the loop is
triggered by a more subtle bug:
When we write a file, we read it to see if the contents have changed.
Writing creates a dependency on the read! So when the error page is
written to disk, it invalidated the read we preformed when we wrote the
main page. That invalidated the main page (and it's node pool), and so
we rendered again. That wrote the main page's code to disk, invalidating
the read of the error page performed when we wrote the error page. ♾️
(I'll be opening more PRs…)
This specifically supports the case where `getStaticProps.notFound =
true` or a matching route is not found, but not the case where
`getStaticPaths.fallback = false` and the route is not enumerated;
This separate case will be implemented in another PR.
Enables the anyhow backtrace feature to capture backtraces for errors
too when `RUST_BACKTRACE` is enabled.
When running in release mode compiling with
`CARGO_PROFILE_RELEASE_DEBUG=1` is recommended to get debug info into
the errors.
Fixes WEB-501
Fixes https://github.com/vercel/turbo/issues/3139
This adds proper support for the [`variable`
property](https://nextjs.org/docs/api-reference/next/font#variable) when
constructing fonts. This results in:
* defining a selector in the css module for a classname defining the css
custom property (css variable), whose value is the font family
* adding a `variable` property to the resulting js object whose value is
the classname used in the selector above
Test Plan: Added an integration test.
When incompatibilities with upgrades to `swc` occur between releases,
these changes expand the existing `pnpm clean` script to additionally
run any `clean` script under any of the lerna packages. In this case, a
new script was created under `packages/next-swc` that removes
`packages/next-swc/native/*`, allowing the default to automatically use
the WASM build.
Users wanting to reset their repository can now run:
```sh
pnpm clean
```
Future packages or outputs that are built should have their `clean`
script remove them to allow for easy repository resetting.
This implements routing by using a-yet-to-be-implemented API exposed by
Next.js. The API follows something similar to:
```typescript
type MakeResolver = (config: NextConfig) => Resolver;
type Resolver = (IncomingMessage, ServerResponse) => Promise<void> | void;
import { makeResolver } from "next/dist/...";
const resolver = makeResolver(nextConfig as object);
// Later, once we have a request we'd like to route:
// We don't care what the promise resolved to, we just want it to settle.
await resolver(req, res);
```
The resolver can do 1 of 3 things with this:
1. ~~Return a redirect response~~ Removed
2. Return a rewrite response
3. Stream a middleware response
> ~~1. Return a redirect response~~
<details>
First, ensure a `x-nextjs-route-result: 1` header is present on the
response. Then return a JSON encoded body:
```typescript
{
url: string,
statusCode: u16,
headers: Record<string, string>
isRedirect: true
}
```
The Rust server will then respond with a redirect using to the
appropriate location.
</details>
> 2. Return a rewrite response
First, ensure a `x-nextjs-route-result: 1` header is present on the
response. Then return a JSON encoded body:
```typescript
{
url: string,
headers: Record<string, string>
}
```
The Rust server will use this updated URL to request content from our
handlers.
> 3. Stream a middleware response
Ensure `x-nextjs-route-result` header **is not present** on the
response. All headers will be sent back, and the body will be streamed
back to the browser.
- - -
TODO:
- ~~Do `headers` actually matter to a `redirect`~~ Yes?
- ~~Does `statusCode` actually matter to a `rewrite`?~~ No
- ~~We can't handle streaming body responses yet.~~ Mocked by buffering.
Fixes WEB-228
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This adds support for metadata in pages and layouts.
Full metadata support also needs support for implicit metadata with
files named `icon.ico` etc.
This PR also improves the test suite and adds a basic test case for app
dir support
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] 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)
In addition to the fix, I've extracted the path regex/params matching logic from `turbopack-node` to `next-core`. `turbopack-node` now only declares a value trait which `next-core` implements.
fixes WEB-141
This changes the ContentSource API.
Before a ContentSource returned a tuple of specificity and content.
Now it returns a tuple of specificity and a get_content function.
The old way made it very inefficient to combine multiple ContentSource.
All combined ContentSources were ask before, all returned specificity
and content, and they are ordered after that. That required to compute
all contents, even if it is not really used after ordering.
Now we order specificity and a get_content function and only compute the
content (by calling get_content) with the final result.
It also changes how data needs are expressed in the `get_content`
function. Instead of asking it over and over again with more data, it
statically returns the needed data with `vary` and the `get` function is
only called with that data. This is technically more limited than the
old way, but one can workaround that if needed. But practically we
probably never need that. On the other hand it improves the number of
function calls, since the `vary` method is only called once and the
`get` only once per request. Before data needs required at least 2 `get`
calls per request.
Our `pageData` HMR process treated an undefined response as an error condition, but if the page doesn't have a `getXyzProps` exported method, then this is the default response. This prevented us from having any pages without page props.
The new code just sends down an empty object, which seems to work for establishing the connection. HMR updates are sent down (and seem to trigger restarts, at least from what I tested with `getStaticProps`).
Fixes WEB-445
