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.
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
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
This updates our `mdxjs` dependency to the tip of
https://github.com/wooorm/mdxjs-rs/pull/11, so that we can update it's
`swc_core` dependency (it conflicts with ours).
It also updates the `testing` crate to update it's `swc_common`
dependency (also conflicting with ours), and makes it a workspace
dependency.
Fixes WEB-412.
Previously, references to styled-jsx inserted by the swc transform would be bundled, which duplicated the copy required by next, which is external. This marks the dependency is to be resolved as external always.
Test Plan: Verified in a small app that `<style jsx>` nodes result in a server-rendered response with the appropriate `<style>` tag in the head.
This implements a debug mode for spawning Node processes across multiple surfaces including `evaluate` and `get_renderer_pool`.
It:
* automatically limits concurrency to 1 process per pool
* passes `--inspect-brk` to spawned Node process
* sets the timeout to effectively-infinite duration
Test Plan: set the value to true for the call to `get_renderer_pool` in render_static.rs and attached to a debuggable server renderer process.
This:
* Implements a basic http server to mock returning a stylesheet from the Google Fonts API (**Note**: This importantly does *not* mock returning the font resources themselves, which are currently loaded by the browser. We should implement something to do this when we implement caching arbitrary http resources traced from `url()` and this is no longer loaded by the test browser)
* Adds an integration test that asserts the basic shape of the JS object returned by font functions
* ~Adds an integration test that asserts the browser correctly loads a font for the ascii unicode range, along with the appropriate `font-display`, variant, etc.~ Unfortunately `document.fonts` is not reliable with different font-display loading patterns as any of them can fall back.
As noted, this does not mock responses from Google for the font resources themselves, which are currently loaded by the test browser. This means that we'll be dependent on this external service for passing integration tests until we implement caching of `url()`s in Turbopack. We should monitor the reliability of this test.
https://github.com/vercel/next.js/pull/44668 refactored Next's use of `AsyncLocalStorage`, and installs a "polyfill" of the API by patching the node import onto `globalThis.` Importantly, it's then used in the module scope during imports, so we need to install the polyfill early in the app rendering startup.
Fixes https://github.com/vercel/turbo/issues/3319
This adds two basic tests for next/dynamic:
* one ensures that SSR supports dynamic components;
* the other ensures that SSR doesn't run when `ssr: false`.
This PR adds the next/dynamic SWC transform to the repo. This is copied
over from the implementation in
[](f70a6bfb86/packages/next-swc/crates/core/src/next_dynamic.rs),
with an additional mode for Turbopack.
For now, it applies it to all sources files (excluding node_modules, but
including embedded modules).
I've refactored the Next transforms logic to make it more easily
extendable in the future, and avoid creating more Vcs than absolutely
necessary.
This PR is the last item in the list of what's needed to support
next/dynamic in development.
The `processed_assets` `IndexSet` was performing deduplication on the `AssetVc`, which is the same between static (`import ... from "foo"`) and dynamic (`import("foo")`) imports of the same specifier. But, the _reference_ to those assets is different, and generates different chunking semantics. In order for both to succeed, we need to process both assets.
Coupled with vercel/turbo#3193's ability to load chunks on the server side, this fixes fixes WEB-381.
add the minimum to run a simple raw-loader (see test case)
* add `experimental.turbopackWebpackLoaders` to next.config.js
* key is extension like `".mdx"`, value is an array of loaders like
`["mdx-loader"]`
This PR separates Turbopack's `runtime.js` into two:
- the Browser/DOM implementation, which uses `<script>` and `<link>`
tags for dynamically loading chunks;
- the Node.js/CommonJS implementation, which uses `require` instead.
~~The two runtimes share a lot of code, but I'm not sure what's the best
approach for sharing this logic, or even if we should, so for now they
are two separate entities.~~
The shared code between the two runtimes is now in a separate file to
avoid duplication.
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
