These opt-outs are dangerous to leave around because they can break local tasks. 100% of the codebase has been migrated over to use `NonLocalValue` for `VcValueType`, so these opt-outs aren't needed.
### What?
add `experimental.turbo.sourceMaps: boolean` which defaults to `true`
When set to `false` it disables:
* emitting source maps for .js and .css
* extracting source map from input source files
* source maps handling in minify
The PR also disables source maps for externals tracing in general since we don't need that
This PR only allows strongly consistent reads to happen on `VcOperation`:
- Moves `Vc::strongly_consistent` to `OperationVc::read_strongly_consistent`.
- Moves `Vc::resolve_strongly_consistent` to `OperationVc::resolve_strongly_consistent` (and makes it return a `ResolvedVc` instead of a `Vc`).
Both these use `OperationVc::connect()` to connect before reading/resolving.
## Why do this?
- For resolved Vcs, the task id associated with the Vc may be unintuitive, as it could be the task that constructs the cell, not the function you most recently called.
- For local Vcs, the task id is our own task. We can't strongly resolve ourselves.
So, the solution is to force strong resolution to occur on `OperationVc`s, where the task pointed to is as obvious as possible.
## Unit Tests
There are still some unit tests depending on `Vc::strongly_consistent`/`Vc::resolve_strongly_consistent`. I'll fix those and completely remove these methods in a subsequent PR.
### What?
Performance and memory fixes during creation of the module graph
-30% memory on module graph, -20% runtime on module graph
* fix apply_esm_specific_options caching
* avoid resolve task for get_exports
* avoid analyse created items being turbo-tasks functions
* avoid reading created Vc
* determine module type per directory
* reduce resolve tasks
* make some functions in module processing non-turbo-tasks-functions, avoid reference type in apply_module_type
* add Option<Vc<T>>::to_resolved
* make esm_resolve a normal function
* make resolve_asset a non-turbo-tasks-function
### What?
Adds a very simple version of Production Chunking for ecmascript which creates chunks in a way that completely avoids duplicating modules.
Future PRs will add more heuristics to that like a minimum chunk size or a maximum number of requests.
`VcArc` represents values passed through napi to next.js and back. Because these values exit the scope of turbo-tasks, similar to how `State` works, they must be operations, so that they're recomputed/"kept alive" when read.
These changes were extracted from @sokra's original `OperationVc` work (mostly preserved here: https://github.com/vercel/next.js/pull/72776), though adapted significantly for the removal of the `OperationVc::new()` constructor.
Build next-swc using the dhat feature:
```
pnpm pack-next --features __internal_dhat-heap
```
### Testing with dev
```
pnpm dev --turbo
```
Hit <kbd>ctrl</kbd>+<kbd>c</kbd>, and see the dhat output:
```
[dhat]: Teardown profiler
dhat: Total: 10,246,437 bytes in 84,934 blocks
dhat: At t-gmax: 4,129,935 bytes in 42,733 blocks
dhat: At t-end: 4,118,268 bytes in 42,728 blocks
dhat: The data has been saved to dhat-heap.json, and is viewable with dhat/dh_view.html
```
### Check that we didn't regress turbotrace
Modify a project's `next.config.mjs` to enable turbotrace:
```
experimental: {
turbotrace: {}
}
```
run `pnpm build` and see that we get output from dhat at the end:
```
dhat: Total: 108,876,305 bytes in 716,123 blocks
dhat: At t-gmax: 53,145,524 bytes in 338,440 blocks
dhat: At t-end: 53,145,524 bytes in 338,440 blocks
dhat: The data has been saved to dhat-heap.json, and is viewable with dhat/dh_view.html
```
Merge `EcmascriptClientReferenceProxyModule` (which only had the proxy
codegen) and `EcmascriptClientReferenceModule` (which only had the
`Isolated` references) into a single module.
There was benefit to splitting them, and this caused problems for single
module graph chunking
Extracted from https://github.com/vercel/next.js/pull/73752
Adds `chunk_group_multiple` which takes a vector of modules, to get rid of the unnecessary `IncludeModulesModule`s that were used to work around that
Everything should be in place now to have the module petgraph be 100% accurate even if its split across multiple graphs (i.e. in dev or because of the actions).
Nothing uses this yet, in the future we should measure if there's a perf impact of running next/dynamic, client references, server actions on the whole graph as opposed to only on the change layout segments (which is what currently happens).
- [x] clean up/ensure that there are always all needed `entries` in the graph struct
`OperationVc`s should be used with `CollectiblesSource` instead of `Vc`s because collectibles represent a side-effect or implicit extra return value of a function's execution.
The new version of Turborepo (rightfully) complains that two of our
packages don't have output files specified when running `pnpm build`:
```
WARNING no output files found for task @next/codemod#build. Please check your `outputs` key in `turbo.json`
WARNING no output files found for task @vercel/turbopack-next#build. Please check your `outputs` key in `turbo.json`
```
The package `@next/codemod` emits its `.js`, `.js.map`, and `.d.ts`
files into the same folder as the respective source files instead of
`dist` (as specified in the root `turbo.json`). And
`@vercel/turbopack-next` does not emit any output files. Both facts are
now reflected in the two added package-specific `turbo.json` files.
This:
- Replaces all use of chunk items in the interface for `chunk_content`
with ChunkableModules
- Moves `is_self_async` from `ChunkItem` to `Module`
- Renames `AvailableChunkItems` to `AvailableModules` and all associated
structs and methods, using modules in place of chunk items
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
This adds the edge weight (the `ChunkingType`) of the edge during
`traverse_edges_from_entry` and `traverse_edges_from_entry_topological`,
rather than only providing only the originating node.
Test Plan: Added a log to verify edge types were provided to these
visitors.
Will be stacked on next React sync which includes
`unstable_ViewTransition`.
Allows using React's `unstable_ViewTransition` Component behind the
`experimental.viewTransition` flag.
Right now it just opts into React's experimental build but may later
house Next.js specific features like Transition Types for navigations.
I checked that the encryption key is now being used as the hash_salt.
I'm not sure about how to add a test for this behavior so let me know
about any suggestions there. (I tried looking for tests that would use
the functions up the call tree without any luck)
While many use case-specific graphs belong in Next.js, this primitive
should be kept in Turbopack as it will be used for other core usecases
like chunking.
Test Plan: CI
Fixes#74062 (`jotai` ran into this error [when they added `"type":
"commonjs"` to their
package.json](https://github.com/pmndrs/jotai/discussions/2579#discussioncomment-9812492))
> this is a bug in the transform we do when a `'use client'` directive
is encountered. I think what's happening is that we're creating a
virtual file that uses ESM import/export syntax, but it's called
proxy.js (not proxy.mjs), so the `"type": "commonjs" `makes turbopack
"correctly" upset at the ESM syntax.
https://github.com/vercel/next.js/issues/74062#issuecomment-2555922867
The (slightly kludgy) solution is to use `proxy.mjs` or `proxy.cjs` to
force the module format, bypassing the issue where `proxy.js` changes
meaning depending on `package.json#type`.
### What?
fixes the computation of `import.meta.url` inside of monorepos (when the root_path != project_path)
### How?
We add a new argument to the ChunkingContext that represents the relative path from the output folder to the root of the monorepo. Since they are on different filesystems, we can't compute them from the values alone.
In #73059 we added build-time checks for the forbidden usage of `this`
and `arguments` in server functions. A nested function expression is
however allowed to use these expressions.
fixes#74181
To add a bit more context: `this` is forbidden in server actions because
the Next.js compiler hoists inline server actions out of their original
location into the module scope, so that they can be imported and invoked
by the action handler. Due to this hoisting, the `this` context gets
lost and is not available to the server action.
To prevent surprising runtime errors for such cases, we emit a build
error to provide feedback to developers as early as possible.
However, nested function declarations or function expressions create a
new `this` context, and in those it's allowed to access `this` and
`arguments`.
For consistency, and to prevent surprises when refactoring server
actions, we apply the same rules for module-level server actions.
`OperationVc`s should be used with `CollectiblesSource` instead of `Vc`s because collectibles represent a side-effect or implicit extra return value of a function's execution.
This PR doesn't convert all callsites, just a handful.
I started writing this PR by requiring `OperationValue` in `State`:
```diff
impl<T> State<T> {
- pub fn new(value: T) -> Self {
+ pub fn new(value: T) -> Self
+ where
+ T: OperationValue,
+ {
```
And then went through changing every compilation error that occurred as a result.
## Hacks
**There are some hacks in a number of places here where we incorrectly convert `ResolvedVc` to `OperationValue`.**
Unfortunately these have to exist because it's impractical to convert everything to `OperationValue`. `OperationValues` are harder to construct as they must be created directly from the return value of an unresolved function call.
## Why does `State<T>` need `T: OperationValue`?
`OperationVc` types require that `.connect()` is called before their value can be read.
As an internally-mutable type, `State` allows `Vc`s to be passed in ways that we cannot track. `.connect()` re-connects the `Vc` to the dependency graph so that strong resolution is possible.
Without this, you might end up with stale results when reading a `Vc` inside of `State`, which can be very hard to debug.
Fundamentally, I think `State` is unsound, but this is a band-aid on it until we can migrate to a better solution (likely effect-style `Collectibles` for `VersionedContentMap`).
Benjamin Woodruff