### What?
* While looking for server component entries and client components, look
for server utils too
* Create a separate chunk group for server utils
* Mark all user imports in the rsc entrypoint has server component
entries
* Fix order of imports to allow proper caching
---------
Co-authored-by: Niklas Mischkulnig <4586894+mischnic@users.noreply.github.com>
Noticed this pattern while touching `turbo-tasks-fs`.
Functions that take `self: Vc<Self>` and immediately await it without ever using the `Vc` version of the argument should just take `&self` as an argument.
There are some remaining cleanup opportunities here, which I have some still-WIP codemods for:
- [x] If we have a trivial `let this = self` or `let this = &self.0`, we should rewrite references to `this` to use `self`. *Done in #70431*
- [ ] If we can be sure that a function never returns anything other than `Ok(...)`, we should remove `Result` from the return type.
Those changes need to be performed as a separate codemod pass due to limitations with `ast-grep`.
## How?
ast-grep: https://ast-grep.github.io/
Using the ast-grep config: https://gist.github.com/bgw/b7bc0a921cf3e3447acaf8feda60b518
Ran it with:
```
sg scan -U -r ../codemod_rewrite_vc_self.yml .
```
## Should this be a lint?
**Maybe.** I've managed to get the false-positive rate down to zero on our existing codebase (at the cost of missing some opportunities for cleanup).
ast-grep supports running as a lint rule, and this can be autofixed. However, if we fix the `let this = ...` and `Result<...>` cases as well with additional lint rules, **this might be a bit annoying as it'll trigger cascading lint rules**. You *might* need to run the linter multiple times for it to eventually settle.
It does not appear to be possible to do all these changes in a single lint rule, as we require modifying overlapping ranges of code (which ast-grep sadly doesn't seem to support with the `rewriters` rules).
We should also consider `dynlint` before heavily investing into `ast-grep` as a linter: https://github.com/trailofbits/dylint
This is of course still not great. Is there a way/will to have
codeframes similar to https://github.com/vercel/turbo/pull/8879 when
using Webpack?
Before:
```
Error: page.mdx:Error: Message { place: Some(Point(7:1 (87))), reason: "Unexpected end of file in expression, expected a corresponding closing brace for `{`", rule_id: "unexpected-eof", source: "markdown-rs" }
Import trace for requested module:
./app/blog/hello-world/page.mdx
⨯ ./app/blog/hello-world/page.mdx
```
After:
```
Error: page.mdx:Error: 7:1: Unexpected end of file in expression, expected a corresponding closing brace for `{` (markdown-rs:unexpected-eof)
Import trace for requested module:
./app/blog/hello-world/page.mdx
⨯ ./app/blog/hello-world/page.mdx
```
Closes PACK-3254
1. Previously, guards were never removed, so a single if statement
containing `if(clearImmediate)` would mean that it's valid in the whole
file to use `clearImmediate` anywhere. Now it's only valid inside the
bodies of conditional. I haven't seen any additional lints caused by
this.
2. `if(process.env.NEXT_RUNTIME === 'edge')` guards are now respected
There are new test cases for each of these.
One new warning from this is the following from
`react/cjs/react.development.js` where the unrelated `typeof` doesn't
silence the error for `new MessageChannel()` anymore
```
function enqueueTask(task) {
if (null === enqueueTaskImpl)
try {
var requireString = ("require" + Math.random()).slice(0, 7);
enqueueTaskImpl = (module && module[requireString]).call(
module,
"timers"
).setImmediate;
} catch (_err) {
enqueueTaskImpl = function (callback) {
!1 === didWarnAboutMessageChannel &&
((didWarnAboutMessageChannel = !0),
"undefined" === typeof MessageChannel &&
console.error(
"This browser does not have a MessageChannel implementation, so enqueuing tasks via await act(async () => ...) will fail. Please file an issue at https://github.com/facebook/react/issues if you encounter this warning."
));
var channel = new MessageChannel(); /// <---------
channel.port1.onmessage = callback;
channel.port2.postMessage(void 0);
};
}
return enqueueTaskImpl(task);
}
```
This is a pure refactoring. Not every reserved file in the app directory represents a component module. Currently, `route` is the only exception, but a future PR will introduce another one.
This is a pure refactoring in preparation for introducing an `app_route_loader_tree` in a future PR.
It enables reusing common logic for injecting imported modules from the app directory into both page and route entries.
This is a pure refactoring in preparation for introducing an `app_route_loader_tree` in a future PR.
The `app_page_loader_tree` collects information from the app directory for app _page_ entries, whereas the upcoming `app_route_loader_tree` will collect information from the app directory tailored to app _route_ entries.
The `app_structure` Rust binding for Node.js is not used anywhere. It was introduced in #47737, but has never been integrated.
Note: The removal is also part of #69680, but we hope to land this earlier in isolation to unblock work that builds on top of it.
### What?
Intercepting routes should only override the slot they are in and not
affect other parts of the tree.
This PR makes sure we replace all other slots with the default route.
Closes PACK-3219
Fixes#69299Closes#69575
### What?
Improve error messages about invalid CSS files.
### Why?
Currently, `sass-loader` compiles CSS as a single line, and as the issue
emitter prints the whole line, the error message is not good.
### How?
Closes PACK-3187
Fixes#68311
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What?
Port more linting features from `webpack/middleware-plugin.ts`.
### Why?
To match the behavior of the default mode.
### How?
Closes PACK-3224
Building on #68698, which causes `Error`s propagated from the
`VersionedContentMap` to surface as errors instead of reloading the
page, allow intentionally missing values to be returned.
There are scenarios in which this is desirable and not an error, such as
when the content of entries change and the page must be reloaded.
In these cases, a `Update:Missing` is returned, which causes the page to
be reloaded.
Test Plan: CI
PACK-3188
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What?
* stable Vcs without TraitRef::cell
* move entrypoints awaiting earlier
* consistent middleware and instrumentation endpoint using a empty
endpoint to avoid errors
* handle error when subscribing to changes
### Why?
Styles imported from RSC are processed twice by webpack loaders and
postcss. This is not only expensive, but can also lead to hanging
problems if both executions doesn't result in the same code (e. g. when
using randomness in webpack loaders).
### What?
Add a transition to styles to place them in the client context when
import on RSC side.
fixes#69643
fixes PACK-3243
### What?
Improves guard detection for node.js process so it can handle code like
`typeof process.off === "function" && process.off()`.
### Why?
It caused several issues for sites.
x-ref: https://vercel.slack.com/archives/C03S8ED1DKM/p1724702057947199
### How?
### What?
When using google fonts, we import files and write them with their hash
to the filesystem. Some of these fonts get very close to the file size
limit which, after appending a hash onto them, causes turbo to fail with
a write error.
### Why?
Different operating systems have different path length requirements. In
short:
- macOS: limit per segment, longer limit for entire path length
- unix: limit per segment, longer limit for entire path length
- windows: hard limit of 260 chars unless using UNC
We need to respect these.
### How?
A small change in the font code that rewrites filesystem paths if they
approach this limit, with some buffer room. ~Rather than truncating I
opted for a 64 bit hash because many fonts have long common prefixes. We
could bump this up to 128 or higher but in practice there will be very
very few files that need this code path.~ _(bgw):_ This now uses a
combination of truncation (for legibility/debuggability) and a 128 bit
hash (for collision avoidance).
Another option is a general handler for this where reads and writes are
intercepted in turbo tasks fs but I wanted to achieve a few things:
- explicitly handle sources of problematic file names at the source,
rather than having a blanket impl
- avoid obscure hashed names appearing in our outputs generally since it
makes debugging harder
- avoid lots of hashing on reads and writes
To me it is safer to have the source ensure they are meeting the needs
of the system since we can control source specific implementations.
Closes PACK-3012
---------
Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>
### What?
Allow to specify transitions via rules.
### Why?
This will enable to apply a transition on every style import and allows to put style imports from RSC in the client context
### What?
Known not existing exports will show an error. But only when they
bindings are actually used. Unused imports won't trigger an error.
```
error - [bindings] .../invalid-export/index.js:1:0 Export Abc doesn't exist in target module
+ v-----------------------------v
1 + import { Abc } from "./module";
+ ^-----------------------------^
2 | // We don't report errors for unused invalid exports
3 | import { Def } from "./module";
4 | import * as X from "./module";
5 |
The export Abc was not found in module [project]/turbopack/crates/turbopack-tests/tests/execution/turbopack/exports/invalid-export/input/invalid-export/module.js [test] (ecmascript) <exports>.
Did you mean to import Abd?
All exports of the module are statically known (It doesn't have dynamic exports). So it's known statically that the requested export doesn't exist.
| These are the exports of the module:
| Abd, Eef, a, b, c
|
```
fixes PACK-3172
Closes#69861
Closes PACK-3240
The sourcemaps of server actions were invalid, the listed source file
was the file `AssetIdent` like
`turbopack://[project]/bench/basic-app/app/actions.ts [app-client]
(ecmascript, action)` instead of only the source file path.
This broke the sourcemap mapping logic of the error overlay.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Previously, in a number of situations, we would implicitly use the entry
module’s ident to name the chunk group. This adds the ability to specify
a different name.
Now, for evaluated chunk groups for pages, we use the page source’s
ident. This prevents changes in loader chunk groups from changing the
chunk name, which breaks HMR.
We still use the entry module’s ident for most other cases now, but it
is now explicitly provided.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/development/acceptance/ReactRefreshModule.test.ts` with #68698
applied
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
An extension of #69762:
> There are also a few more of these helpers if you search for `_boxed(`.
These things used to be needed before Rust 1.77.0: https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html#support-for-recursion-in-async-fn
These days, we can just do the boxing inline!
I also noticed we could remove the `async-recursion` macro, as it's not providing much value on Rust >=1.77.0.
If a Rust Error Result is returned by an hmr update, then an unexpected internal error unrelated to the user’s code has occurred. Like #67678 does for unhandled panics, log these errors to a file and inform the user with a generic message informing them to file an issue. In development, this continues to log to stderr.
## What?
This implements passing the browerslist config from Next.js to
Turbopack. Initially I implemented passing the user browserslist config
in this PR as well but found that when this is lowered it causes test
failures, those need to be investigated separately but shouldn't block
these changes landing.
<!-- 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 #
-->
While investigating #65614 I found that in Next.js with webpack we mark
this dependency as external but in Turbopack we didn't do that yet,
causing it to be bundled and then fail at runtime because the path
didn't match exactly. This PR ensures it's marked as external.
Didn't add an additional test as we still have some Turbopack build test
failures related to opengraph images so potentially this change also
fixes those 💯
Fixes PACK-3058
Fixes#65614
<!-- 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 #
-->
### What
The node.js pool doesn't need to be invalidated when pool code is
re-writting. It's enough to invalidate it when the pool code has
changed.
Avoid having transient tasks in the embedded filesystem. It's not allow
to have persistent tasks depend on transient tasks with Persistent
Caching.
Avoid triggering invalidation when State is dropped. State might be
dropped after serialization when it's stored in persistent cache. This
doesn't mean we want to invalidate the tasks
### What?
We can't pass the whole config (including next config) as argument to `ProjectContainer::new` as this would result in a new project every time the config is different. (It's always different due to some random values).
So to leverage persistent caching we need to remove the argument from `ProjectContainer::new` (so it's always the same project) and push the config into a `State`. This way we "modify" the project and can benefit from caching for the unchanged values.
Found that middleware matchers were not fully implemented. Copied the
implementation we have for webpack as much as possible. Had to add a
workaround for path-to-regexp being used so now we post-processes the
manifest that the compiler outputs to turn the path-to-regexp string to
a regex.
<!-- 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 #
-->
Fixes the tests related to `config.regions` with Turbopack. There's
another case for Pages Router using edge runtime exporting the same
config. I'm going to implement that in a follow-up PR.
After implementing `regions` and making sure `wasm` and `assets` stay in
the manifest when empty (to pass another middleware test) I found that
`assets` was not implemented yet, causing the changes in this PR to fail
other tests related to `next/og` because that ships with a default font
file that it tries to load.
Since it was failing the PR and thus blocking the changes related to
`regions` I've implemented `assets` as well.
<!-- 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 #
-->
Tobias Koppers