### What?
Check if the file is a file that is _interesting_ to the React Compiler before passing it to the React Compiler
### Why?
It would skip the majority of files
Sets up a flag that will depend on an experimental React feature
(Activity). I based this on the existing code for the `viewTransition`
flag.
I haven't implemented anything behind this flag yet; this only wires up
the flag itself. I added a basic test that renders the Activity
component to verify that it's available when the flag is on.
Closes PACK-4263
This:
- Adds support for using `config.turbopack` for Turbopack. The accepted value for this option is identical to the previous experimental one without the deprecated field `loaders`.
- Deprecates `config.experimental.turbo`. Warns on its use, but will continue to accept it, merging it with `config.turbopack` while preferring fields on `config.turbopack`.
- also see https://github.com/vercel/next.js/pull/77850#pullrequestreview-2749738760
Test Plan:
- [x] Convert use of `config.experimental.turbo` in tests to `config.turbopack`
- [x] Automated test for accepting the experimental option for compatibility, as well as the config merging
Adds a build script for `next-error-code-swc-plugin`, runnable via `pnpm
build-error-code-plugin`. The script compiles the plugin and moves the
result to its expected location in
`packages/next/next_error_code_swc_plugin.wasm`.
I've also rebuilt the plugin and committed it -- i was getting a
different compiled output that what's currently there. Not sure if the
build is non-deterministic, a dependency changed, or if someone forgot
to recompile it, but it can't hurt.
### Why?
Before `get_endpoints` gives you a lot of `Vc<Endpoint>`, which we keep around and subscribe to. That is a problem as endpoint can also vanish at any time. e. g. when the folder is removed.
`Vc<Endpoint>` was not able to represent this state. The subscription throw an error as the Vc is no longer existant. So the error was technically correct here (not a bug in turbo-tasks).
But in practice we don't want to have this error. We want to have a clean end of the subscription without any error. That's why I change it to `Vc<Option<Endpoint>>`, which allows to represent the non-existance of an endpoint.
This can (resp. need to be) handled in subscriptions, which can report e. g. a `NotFound` result or a change event (for server_changed).
### What?
avoid having inactive Vcs when routes are removed.
instead use an `Option<Endpoint>` to allow respresenting removed endpoints and handle these in subscriptions correctly.
### What?
Instead of embedding the chunk filename into the chunk itself (which is a probably for content hashing), use `document.currentScript` to grab the chunk path.
### What?
Change the signuture of `ChunkingContext::chunk_path` to take an `Asset` argument. The `content()` of the `Asset` might be used in future generate a content hash for the chunk path
I suspect the test failures in https://github.com/vercel/next.js/pull/77661 are related to a `Vc` that should be an `OperationVc`.
I realized that we have so few uses of `Vc` inside structs and enums that it might be easier to work off of that list than to carefully audit my changes in my other PR, though it doesn't look like anything's a smoking gun here.
Either way, while it's totally valid for non-`VcValueType` structs and enums to contain unresolved `Vc`s, it's usually suboptimal, and there should probably at least be a comment explaining the choice to use an unresolved `Vc`.
I still have a long-term goal of renaming `ResolvedVc` to `Vc` and the current version of `Vc` to `UnresolvedVc`, so for that reason alone, I want everything to prefer using `ResolvedVc` "by default".
It's totally valid for `TaskInput`s to use `Vc`, but `ResolvedVc` is marginally more preferable for a number of performance and functionality reasons (a sane `Eq`+`Hash` impl, doing work more eagerly, synchronous downcasting support).
This:
- Adds a test asserting the user can override the tsconfig path via the
next-config. This is already supported with Next.js and Webpack.
- Implements the necessary code to pass the test and implement support
with Turbopack.
Test Plan: `pnpm test-dev test/e2e/tsconfig-path/index.test.ts && pnpm
test-dev-turbo test/e2e/tsconfig-path/index.test.ts`
Closes PACK-4215
### What?
Ensuring server-side processing for the loader function of
`next/dynamic` with `ssr: false` is properly skipped in Turbopack.
### Why?
Previously, client components imported through `next/dynamic` with `ssr:
false` were not skipped, while they are skipped in webpack. This fix
ensures consistent behavior between Webpack and Turbopack. This is a
compilation performance win for applications that leverage this pattern
heavily, as it can skip work it doesn't need to process.
Was looking at fixing one of the failing tests in the list of remaining
tests. Found it checked for this behavior and fixed it.
### How?
- Added the same `should_skip_ssr_compile` logic to the Turbopack state
that was already implemented for Webpack
- When `ssr: false` is specified and we're in the server compiler we
replace the dynamic import with an empty async function to avoid
bundling the client component on the server
For a tracing GC to work (different for cache eviction), we need `TraceRawVcs` to be able to inspect function arguments.
While a tracing GC is still far off, the immediate motivation here is using tracing to improve logging for "transient task called from persistent task" error messages.
There's one non-test mpsc queue (`ComputeUpdateStreamSender`) with a sketchy `TraceRawVcs` impl. We should have a way of excluding certain objects from GC (marking them as roots) to fix this in the GC case. IMO this doesn't really matter for non-GC debug use-cases of `TraceRawVcs`.
Closes PACK-4072
Ignore static asset imports in Edge, these are really intended for the client (i.e. for
pages and not routes, for example `import logo from "./logo.svg"`), while still allowing `new URL(..., import.meta.url)`.
This replicates what Webpack does. A proper solution for assets on Edge would require some change on the Next.js side to actually tell the bundler if an asset is intended for the server (e.g. for next/og: wasm, fonts), or for the browser.
### What?
Port the webpack css chunking implementation for app dir to Turbopack.
It also computes ordered entries in module batches
Pages router also uses the app dir chunking, but that's incorrect and leads to some breaking test cases.
### What?
Use `rayon` for parallelism
### Why?
`chili` seems to have some bugs regarding the CPU usage of heartbeat thread in idle mode.
### How?
- Closes https://github.com/vercel/next.js/issues/77192
Closes PACK-3715
This also required some changes to the dev loader, as since
https://github.com/vercel/next.js/commit/bc05ce9, app and document are
used from the page bundle itself, and not from the app and document.
~~`_app.js` and `_document.js` are chunked first before the page (this
result is then cached and reused across pages).~~
~~Here, `_document.js` which includes lodash is only chunked once as
part of `page3.js` and the other two reuse that.~~
### What?
Enable a very simple chunking for CSS. It's just chunking by batches, which should cause correct styling, but it not optimal from request count.
Closes PACK-4074
We really need to look into getting e2e tests for correct sourcemaps: PACK-4142
Fix Turbopack server action tree shaking by explicitly splitting up that module
```js
/* __next_internal_action_entry_do_not_use__ {"00c18c215a6b7cdc64bf709f3a714ffdef1bf9651d":"default","70e10665baac148856374b2789aceb970f66fec33e":"myAction"} */ import { createServerReference, callServer, findSourceMapURL } from "private-next-rsc-action-client-wrapper";
export var foo = /*#__PURE__*/ createServerReference("70e10665baac148856374b2789aceb970f66fec33e", callServer, void 0, findSourceMapURL, "myAction");
export var bar = /*#__PURE__*/ createServerReference("00c18c215a6b7cdc64bf709f3a714ffdef1bf9651d", callServer, void 0, findSourceMapURL, "default");
```
->
```js
"use turbopack no side effects";
export { foo } from "data:text/javascript,%2F%2A%20__next_internal_action_entry_do_not_use__%20%7B%2200ab21efdafbe611287bc25c0462b1e0510d13e48b%22%3A%22foo%22%7D%20%2A%2F%22use%20turbopack%20no%20side%20effects%22%3Bimport%7BcreateServerReference%2CcallServer%2CfindSourceMapURL%7Dfrom%22private-next-rsc-action-client-wrapper%22%3Bexport%20var%20foo%3D%2F%2A%23__PURE__%2A%2FcreateServerReference%28%2200ab21efdafbe611287bc25c0462b1e0510d13e48b%22%2CcallServer%2Cvoid%200%2CfindSourceMapURL%2C%22foo%22%29%3B";
export { bar } from "data:text/javascript,%2F%2A%20__next_internal_action_entry_do_not_use__%20%7B%2200ac840dcaf5e8197cb02b7f3a43c119b7a770b272%22%3A%22bar%22%7D%20%2A%2F%22use%20turbopack%20no%20side%20effects%22%3Bimport%7BcreateServerReference%2CcallServer%2CfindSourceMapURL%7Dfrom%22private-next-rsc-action-client-wrapper%22%3Bexport%20var%20bar%3D%2F%2A%23__PURE__%2A%2FcreateServerReference%28%2200ac840dcaf5e8197cb02b7f3a43c119b7a770b272%22%2CcallServer%2Cvoid%200%2CfindSourceMapURL%2C%22bar%22%29%3B";
````
- [x] Keep [sourcemaps](https://github.com/vercel/next.js/blob/canary/test/development/app-dir/source-mapping/README.md#server-actions)
### What?
Previously, `styled_jsx.useLightningcss` was not passed correctly. This PR fixes it.
### Why?
It's required to enable lightningcss mode for styled-jsx.
### What?
Remove magic comments for disabling export merging in the advanced tree shaking of turbopack.
### Why?
Turbopack magic comments for tree shaking + server actions are not required anymore since https://github.com/vercel/next.js/pull/76938.
Closes PACK-3731
This test was effectively already passing, except that we unnecessarily always emitted manifests.
No need to emit the various client reference, next dynamic, server actions, ... manifests for static metadata routes.
Builds on #76814
Closes PACK-4071 (implementing config.deploymentId)
This uses the new `__turbopack_load_by_url__` to load chunks through
client references in react-dom-turbopack.
After this lands I'm going to send a PR to react-dom-turbopack to switch
the original source to use `__turbopack_load_by_url__` too, landing this
PR first to make sure it passes all the Next.js tests.
<!-- 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:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
This implements a new napi binding, `project.writeAllEndpointsToDisk`
which writes chunks for all endpoints.
This avoids iterating over each endpoint and calling individual napi
bindings, each resulting in a call to `emit()`. While iterating entry
points now occurs in Rust, `OutputAssets` are collected in an `IndexSet`
to prevent unnecessary `emit()` calls. This also significantly reduces
unnecessary calls to the manifest loader from JS.
Test Plan: CI
Commit before removing merge commits:
https://github.com/vercel/next.js/pull/75304/commits/189743dd261a682c5cb0a46e69f27861c612e9c2
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What?
Fix the span of the turbopack tree shaking magic comment.
### Why?
Previously it was printed on strange position.
### How?
Closes NAR-91
Closes PACK-4087
When Turbopack creates the default not-found entry, it does so without
providing a default root layout in case one is missing. This works ok in
Webpack since the `default-layout` is correctly added in
[next-app-loader](https://github.com/vercel/next.js/blob/4518bc91641a0fd938664b781e12ae7c145f3396/packages/next/src/build/webpack/loaders/next-app-loader/index.ts#L339-L342).
Looking at the [original
PR](https://github.com/vercel/next.js/pull/54199) that added
`default-layout` it seems it was only really ever intended for the
not-found entrypoint since in all other cases, a missing root layout
means we create one for you in dev and in build it'd be a hard error.
This also includes the other defaults that are correctly added in other
entries to match Webpack behavior. Though I'm not sure the presence of
these makes a difference when rendering the not found page
Closes NDX-858
`HashMap` strikes again, causing the server action manifest order to be non-deterministic.
Less test flakeyness for `app-dir - server-action-period-hash-custom-key should have different manifest if the encryption key from process env is same`
Donny/강동윤
