## What?
These values were only provided to emit events and not for the actual
handling of jsconfig/tsconfig `paths` and such, those are handled
separately by Turbopack itself. This removes the events as they're no
longer relevant and it's not worth slowing down dev/build for them.
<!-- 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 #
-->
update Rspack to 1.4.2, in this version we fix bugs when using Rspack
persistent cache in next.js.
Now user can try Rspack persistent cache by follow way:
```js
const config = {
webpack: (config) => {
config.experiments.cache = {
type: 'persistent'
};
return config;
},
};
```
# Enhance Layer Names with User-Friendly Descriptions
This PR improves the developer experience by enhancing layer names in Turbopack with user-friendly descriptions. Instead of just using internal identifiers like "app-client" or "app-rsc", the PR adds descriptive names like "Client Component Browser" or "Server Component" that better communicate the purpose of each layer to developers.
Key changes:
- Created a new `LayerName` struct that contains both the internal name and an optional user-friendly description
- Updated all layer references throughout the codebase to use this new structure
- Changed error message text from "Example import trace(s)" to "Import trace(s)" for more simplicty
These changes make error messages and debugging information more intuitive, helping developers better understand which part of the application is experiencing issues.
When turbopack reports an issue, compute a set of import-traces for that file so the user can better understand the context of the issue and trivially answer questions like:
* Why is this file included at all?
* Why does next think this is a client-component?
To do this we leverage the `SingleModuleGraph` and use the `astar` algorithm from `petgraph` to compute the shortest path to a root module. This isn't the most optimal approach but should be sufficient since we don't anticipate this being a performance issue.
A complex part of this is that the module-graph tracks the relationships between _modules_ but Issues are associated with _files_. While modules are also associated with files this is a many-to-one relationship. This is why we might report _multiple_ traces for a single issue and also why a single file might appear multiple times in a trace.
## Open formatting questions
* how should we represent paths from other 'filesystems'?
- for disk filesystems i could compute relative paths to the root of the current directory? the `[project]` filesystem? For now i just use the filesystem name as a hypothetically cromulent root.
## Alternatives
The main alternative investigated was associating Issues with `Modules` by collecting them during graph construction. This unfortunately proved to be a non-trivial performance regression and so it was abandoned. The core problem is that we would need to introduce additional `OperationVc` and task roots to simply `collect` the issues. This also wouldn't eliminate the duplicate traces issue, and instead we might end up reporting duplicate issues instead.
## Performance
TODO
Closes PACK-4105
Continuation of https://github.com/vercel/next.js/pull/78166 this
implements the `handler` interface for pages routes, This does not move
the response handling inside of the handler yet as that will be in a
follow-up PR to keep the changes isolated. This still returns the
`RenderResult` for the `base-server` to continue to handle.
Validated against `vercel/vercel` deploy tests here
https://github.com/vercel/vercel/pull/13349
In development when handling the page request, we are sending the
parsedUrl with the basePath stripped but not assetPrefix. As a result,
when setting an assetPrefix, the chunk would 404 which causes a hard
nav. It'd then recover and work correctly on subsequent navs.
This applies the exact same handling we had for basePath, but for
assetPrefix.
Fixes#77241
rip. you served a purpose once, but now you're just getting in the way. this improves typesafety quite a bit, because `BrowserInterface` had a whole bunch of random `any`s everywhere
also
- removes `evalAsync`. no idea why that was needed, but we're happily using promises in normal eval, so it can be dropped
- adds more safety to `chain`
Excludes `/_next/image` and `/_next/static/media` as they don't contain sensitive information and prevents complications loading them in cases where they are inlined in CSS, as they'll be requested with `sec-fetch-mode: no-cors`.
x-ref: https://github.com/vercel/next.js/issues/77344
We have special development endpoints that are also prefixed under `/__nextjs`. This updates the origin checking logic to account for those in addition to `/_next`, and adds a test.
To avoid breaking local development proxies and more complex setups,
this ensures that we only block cross-origin development requests when
opting into the configuration. In a future major release, this will not
be opt-in, and will require explicitly providing the allowed origins
that can access the special `/_next` endpoints.
This adds a warning when a cross origin request is detected that would
be blocked without explicit configuration.
Fixes#77073Fixes#77253Fixes#77344
This ensures we don't allow cross-origin requests to be made to `/_next`
resources in dev mode. This matches existing handling that
webpack-dev-middleware does as well.
This PR removed the old overlay including the deprecated `buildActivity`
and `appIsrStatus` options.
Closes NDX-785
Closes NDX-855
Closes NDX-865
Closes NDX-866
Closes NDX-867
Closes NDX-868
- `newDevOverlay: true` by default (enables experimental React builds on
canary until owner stacks progress further)
- `run-tests` now sets the env var for tests that were relying on it for
forking behavior
- PPR runners now run with the flag disabled to help catch regressions
in the old overlay until we remove it
- Fixed a number of tests that had outdated snapshots or missed forking
behavior because they weren't running in CI
- Disabled a test that was failing in Turbopack + Experimental React
that is unrelated to the overlay (see:
https://github.com/vercel/next.js/pull/75989)
---------
Co-authored-by: devjiwonchoi <devjiwonchoi@gmail.com>
The `--no-mangling` CLI option for `next build` was originally
introduced in #42633. However, we lost this feature during our migration
from Terser to SWC. As part of broader improvements for debugging
dynamic accesses with Dynamic I/O enabled, I needed this functionality
back, so I restored it for Webpack and also added it to Turbopack.
fixes#67037fixes#50208
---------
Co-authored-by: Benjamin Woodruff <benjamin.woodruff@vercel.com>
Currently, for `handleEntrypoints`, `handlePagesErrorRoute`,
`handleRouteType`, etc, both dev and prod use cases are combined into
the same functions. This leads to a lot of branching, use-case-specific
arguments, etc. for minimal opportunity for shared code.
In a following PR, entrypoint writing for prod will be done through a
single napi call to rust, further branching the two versions.
This splits them formally, at the cost of duplicating a handful of lines
in each case. Perhaps in the future we can develop a better system for
sharing code, but this makes things far clearer and easier to maintain
in this moment.
Test Plan: CI
- Before, there was a separate AST traversal that collected `next-dynamic` imports
- Now, we use transitions (which are inserted by the existing next-custom-transform) to tell Turbopack about the next-dynamic imports
- Unlike Webpack (where the react-loadable identifiers are `path/to/parent-module -> ./imported-client`), Turbopack just uses the module id: `[project]/path/to/imported-client.js [app-client] (ecmascript, next/dynamic entry)`
- the `next-dynamic` transition only inserts the marker module (i.e. for the SSR `import()`)
- the `next-dynamic-client` transition inserts the marker module and changes the module context (used to get the client module name)
- Now, we use the correct `AvailabilityInfo` for the next/dynamic chunks to preload, and they are not explicitly emitted. If they are for some reason not the same chunks that are actually emitted for the dynamic import, you get a hard error. (Previously, they didn't use the same `AvailabilityInfo` as the real async chunks, so they usually bundled another copy of React, and also had a different chunk name hash)
- For Turbopack, react-loadable manifests are now scoped per page instead of globally
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
Moved to a separate file to run the test in parallel.
> [!NOTE]
> The "Test new tests for flakes" may fail due to the number of tests in
a single `hmr.test.ts` file.
> The follow-up stacks are to resolve the issue.
### Why?
The test util `check` is deprecated internally, recommended to replace
to `retry`.
Tim Neutkens