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