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.
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.
