~Due to the entry preloading that was enabled by default in #65289, VS
Code is no longer able to map symbols correctly for production builds.
As a temporary solution, we can disable the preloading when a debugger
is started until a proper fix is found.~
By optionally building the Next.js source code with
`NEXT_SERVER_EVAL_SOURCE_MAPS=1` we can ensure, even with the bundled
next server in the node runtime, that the original names are shown in
the debug "Variables" section.
In addition, the `sourceMapPathOverrides` are improved to cover the
different variations of source mapping URLs. We can now also set
breakpoints in the `example/...` and `test/e2e/...` server components.
~Supersedes #66229~
#### Before
<img width="1276" alt="Screenshot 2024-05-27 at 21 36 52"
src="https://github.com/vercel/next.js/assets/761683/f2840c35-f683-445d-bc95-cac9f719d8e7">
#### After
<img width="1276" alt="Screenshot 2024-05-27 at 21 38 42"
src="https://github.com/vercel/next.js/assets/761683/c801c123-3163-46c3-b442-5b72c0a5d51d">
Now that `isNodeDebugging` is not needed anymore in #66254, we can
re-create #66229.
The last usage of the `isNodeDebugging` option was removed in #55383.
I think the wrap function is a leftover from before #66767. We don't
need to return a tuple here, and can just use the `AfterContext`
directly on the call site. This makes its optionality a bit more
obvious, and avoids the noop callback.
### What?
This disallows merging of global css with styles that appear on other
pages/chunk groups.
### Why?
Before we made the assumption that all CSS is written in a way that it
only affects the elements it should really affect.
In general writing CSS in that way is recommended. In App Router styles
are only added and never removed. This means when a user uses
client-side navigations to navigate the application, styles from all
previous pages are still active on the current page. To avoid visual
artefacts one need to write CSS in a way that it only affects certain
elements. Usually this can be archived by using class names. CSS Modules
even enforce this recommendation.
Assuming that all styles are written this way allows to optimize CSS
loading as request count can be reduced when (small) styles are merged
together.
But turns out that some applications are written differently. They use
global styles that are not scoped to a class name (e. g. to `body`
directly instead) and use them in different sections of the application.
They are structured in a way that doesn't allow client-side navigations
between these sections. This should be valid too, which makes our
assumption not always holding true.
This PR changes the algorithm so we only make that assumption for CSS
Modules, but not for global CSS. While this affects the ability to
optimize, applications usually do not use too much global CSS files, so
that can be accepted.
fixes#64773
Previously, if `artifact_directory` were set, artifacts would be
resolved at a fixed location relative to each file. This correctly
resolves them from the project root.
Test Plan: `TURBOPACK_BUILD=1 TURBOPACK=1 pnpm test-dev
test/integration/relay-graphql-swc-multi-project/test/index.test.js`
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What
Transpile `geist` package by default. Currently users need to add
`geist` into `transpilePackages` to make it work with pages router as
it's external packages but require transform. This PR will resolve that
issue. cc @JohnPhamous
### Why
geist package is using `next/font` which requires to work with SWC
transform. But so far only ESM syntax can be captured by SWC since CJS
is pretty difficult to cover as the package import is not statically
analyzable.
We introduced a new list that it could be transpiled and include geist
package into bundle. Add it in both `next/jest` side and
webpack/turbopack bundling side
---------
Co-authored-by: 강동윤 (Donny) <kdy1997.dev@gmail.com>
I was reading the documentation related to MDX and noticed a typo in
some articles, so I fixed them.
Although I read the [Contribution
Guidelines](https://github.com/vercel/next.js/blob/canary/contributing.md)
this is my first contribution so feel free to comment if I can do
better.
Co-authored-by: Jiwon Choi <devjiwonchoi@gmail.com>
### What
When using `generateStaticParams` with interception routes, the
interception would never occur, and instead an MPA navigation would take
place to the targeted link.
### Why
For interception rewrites, we use a `__NEXT_EMPTY_PARAM__` marker (in
place of the actual param slot, eg `:locale`) for any params that are
discovered prior to the interception marker. This is because during
route resolution, the `params` for the interception route might not
contain the same `params` for the page that triggered the interception.
The dynamic params are then extracted from `FlightRouterState` at render
time. However, when `generateStaticParams` is present, the
`FlightRouterState` header is stripped from the request, so it isn't
able to extract the dynamic params and so the router thinks the new tree
is a new root layout, hence the MPA navigation.
### How
This removes the `__NEXT_EMPTY_PARAM__` hack and several spots where we
were forcing interception routes to be dynamic as a workaround to the
above bug. Now when resolving the route, if the request was to an
interception route, we extract the dynamic params from the request
before constructing the final rewritten URL. This will ensure that the
params from the "current" route are available in addition to the params
from the interception route without needing to defer until render.
Fixes#65192Fixes#52880
Tobias Koppers - fix typo (vercel/turbo#8619)
Benjamin Woodruff - Store aggregate read/execute count statistics
(vercel/turbo#8286)
Tobias Koppers - box InProgress task state (vercel/turbo#8644)
Tobias Koppers - Task Edges Set/List (vercel/turbo#8624)
Benjamin Woodruff - Memory: Use `triomphe::Arc` for `SharedReference`
(vercel/turbo#8622)
Will Binns-Smith - chore: release npm packages (vercel/turbo#8614)
Will Binns-Smith - devlow-bench: add git branch and sha to datapoints
(vercel/turbo#8602)
---
Fixes a `triomphe` package version conflict between turbopack and swc by
bumping it from 0.1.11 to 0.1.13.
### What?
Pass `module: "unknown"` to the minifier.
### Why?
It can minify both a module and a script. `module: "unknown"` lets the
parser to detect the type of the program.
The problematic library is `react-pdf` and next.js currently errors with
```
Failed to compile.
static/media/pdf.worker.1f09ce21.mjs from Terser
x 'import', and 'export' cannot be used outside of module code
,-[56104:1]
56104 | const pdfjsBuild = "0cec64437";
56105 |
56106 | var __webpack_exports__WorkerMessageHandler = __webpack_exports__.WorkerMessageHandler;
56107 | export { __webpack_exports__WorkerMessageHandler as WorkerMessageHandler };
: ^^^^^^
56108 |
56109 | //# sourceMappingURL=pdf.worker.mjs.map
`----
Caused by:
0: failed to parse input file
1: Syntax Error
Error:
x 'import', and 'export' cannot be used outside of module code
,-[56104:1]
```
### How?
Related:
https://github.com/vercel/next.js/discussions/30237#discussioncomment-9735075
### What?
Parallel routes build in a weird and render in a weird way.
To render next.js always uses the last parallel route (alphabetically I
think) as that's most likely to be the root.
Building works in the opposite order, it goes from the first to the
last.
This is fine for the first render, but after that the renderer will only
check if the file for the last parallel route has a bundle on disk and
never request it to be updated.
1. match on routes
2. build match
3. check if the last parallel route bundle exists on disk
- if it doesn't so go back to step 2 with the next match
- the actual match gets thrown away
4. render with the bundle for the last parallel route
The condition in step 3 will always be true after an update, because it
was built for a previous request
To fix this, turbopack will now emit all parallel routes that match a
path every time one of them gets requested.
Closes PACK-3078
Fixes#65836
### What
When PPR is off, app router prefetches will render the component tree up
until it encounters a `loading` segment, at which point it'll just
return some metadata about the segment and won't do any further
rendering. This is an optimization to ensure prefetches are lightweight
and don't potentially invoke expensive dynamic subtrees. However,
there's a bug in this logic that is causing it to bail unexpectedly if a
segment deeper in the tree contained a `loading.js` file.
This would mean the loading state wouldn't be triggered until the second
request for the full RSC data is initiated, resulting in an unintended
delta between when a link is clicked and the loading state is shown.
### Why
The `shouldSkipComponentTree` flag was incorrectly being set to `true`
even if the `loading.js` segment appeared deeper in the tree. Prefetch
requests from the client will always contain `FlightRouterState`, so the
logic to check for loading deeper in the tree will always be missed.
### How
This removes the `flightRouterState` check as it doesn't make sense:
prefetches will currently _always_ include the `flightRouterState`,
causing this to always short-circuit. I believe that this check is
vestigial from when we were generating static `prefetch.rsc` outputs
which is no longer the case.
This mirrors a [similar
check](b87d8fc499/packages/next/src/server/app-render/create-component-tree.tsx (L393))
when determining if parallel route(s) should be rendered.
This leverages [fetch
priority](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#priority)
to ensure automatic prefetching as a result of visiting a page is sent
with "low" priority, to signal to the browser it can prioritize more
important work necessary for rendering the page.
A "temporary" prefetch (ie one that is created when there wasn't an
existing prefetch cache entry on navigation) will use a "high" priority
because it's critical to the navigation event.
All other cases will be "auto" which is the current default.
## History
When we added `priority` prop to `next/image`, there was no
`fetchPriority` so we instead used this to preload the image in the
head.
Then when browsers added support `fetchPriority`, we automatically added
`fetchPriority=high` when `priority={true}` to signal to the browser
that this was a high priority image. This priority is added to the img
and the preload.
However, we saw cases where images are blocking critical css. Per
@gnoff:
> React currently prioritizes font preloads then high priority images,
then css in the initial page load
Due to these changes in React (aka Float), we should no longer set
`fetchPriority=high`, although the user can still manually add that prop
if needed.
### Why?
Identified the bottleneck of Turbopack HMR, one of the reason is that we
run `execSync` to get user's package manager and fetch their registry to
get the latest & canary version of Next.js.
This process was located at the initial of HMR, which could have been
delayed to the initial of the error handling.
### How?
- Remove getting user's package manager and just fetch from NPM
regardless the user uses Yarn.
- Used an async IIFE to await the promise of `getVerionInfo` value
inside the synchronous `ws.handleUpgrade`.
### Benchmark
> Benchmarked with console inside try-finally
#### Webpack -- no cache
| Version | Ready |
|-------------------------------------|---------|
| Canary | 1185ms |
| Delta | 896ms |
| Delta Webpack vs Canary Webpack | -24.39% |
#### Turbopack
| Version | Ready |
|-------------------------------------|---------|
| Canary | 1002ms |
| Delta (Turbopack) | 509ms |
| Delta Turbopack vs Canary Turbopack | -49.20% |
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What
* Warn with next.js when users customized `experimental.esmExternals`
value
* Add telemetry tracking on the customization usage for that flag. 0 for
no customization, 1 for used non-default customized value
### Why
`esmExternals` ideally can just remain as default value `true` which
Next.js can handle the customization properly. Since next.js app router
also supports it on canary now we're adding a warning to users that
don't modify `esmExternals` option as it could affect module resolution
on ESM packages.
### Why?
It could be confusing between `...` and `…`, which the later is actually
a single character.
### How?
We throw if we detect `…` instead of `...`.
The Image Optimization API currently uses `parseInt()` for `w` and `q`
query string parameters.
This doesn't handle floats as you might expect and instead coerces, for
example `parseInt('99.9') === 99`.
This PR changes the runtime to match the build time validation and only
accept integers for `w` and `q`.
When a server action responds with something other than an RSC response,
we currently silently ignore the error and it doesn't get propagated to
any rejection handlers.
This adjusts the handling so that if the server action response is a
non-successful status code, we reject the server action promise. If the
error is `text/plain`, we'll automatically propagate the text content as
the error text. Otherwise, the promise is rejected with a fallback
message.
## Description
This Pull Request improves the visual appearance of the badges in the
README.md file by removing unnecessary line breaks between the badge
images, eliminating the unwanted blue link lines that previously
appeared and resulting in a cleaner and more cohesive look.
### What
Removed unnecessary line breaks between badge images in the README.md
file to eliminate the unwanted blue link lines and improve the overall
visual presentation.
### Why
Previously, the badges were displayed with line breaks between them,
causing blue link lines to appear, which disrupted the clean look of the
badges. By removing these line breaks, the badges now appear without the
blue link lines, providing a more cohesive and visually appealing
README.
### How
- Removed the line breaks between badge images in the README.md file.
Co-authored-by: Jiwon Choi <devjiwonchoi@gmail.com>
Previously, when the provided postponed state was corrupted, the render
failed which resulted in a hydration error. Instead, when the postponed
state is corrupted, we send the resume stream just for the hydration
where it'll attempt to render client side with the data that's already
available.
### What?
This makes extracting next/dynamic cheaper when modules have been visited before
### Why?
improved HMR and page transitions
### How?
All steps for visiting a module are extracted into a single cached function. VIsiting already visited modules costs only a single cache lookup