This removes the `lazyDataResolved` property on the CacheNode -- it was
added to avoid repeatedly applying the server-patch action while data is
missing (and while waiting for the server to respond), but if we just
move the patch action be attached to then server fetch, there's no need
to separate these (we're already suspending indefinitely while data is
missing)
This refactors our handling of passing routing information to the render
logic via headers which is legacy from when we had separate routing and
render workers. Now this will just attach this meta in our normal
request meta handling which is more consistent and type safe.
### What?
I replaced `let` with `const` for `useState`.
### Why?
Since in these examples, it doesn't need to be a `let`, as it doesn't do
any reassignment.
add (Experimental) to title for `unstable_rethrow` to match all other
`unstable_` functions
### Fixing a bug
- Related issues linked using `fixes #66966`
<img width="1287" alt="image"
src="https://github.com/vercel/next.js/assets/147033096/5a790b63-30c9-4605-b0e8-73899afb8e59">
## For Maintainers
`unstable_rethrow` has a different title scheme compared to all other
`unstable_` functions this is just a quick fix for this since it was
bugging me.
Closes NEXT-66966
Fixes#66966
---------
Co-authored-by: Sam Ko <sam@vercel.com>
We've run into numerous issues with local system configurations that
prefer ipv6 and failing to connect to the test proxy.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
This PR adds [Lingui](https://lingui.dev) to the list of i18n resources
on the
[Internationalization](https://nextjs.org/docs/app/building-your-application/routing/internationalization#resources)
page for the App Router.
### Why?
Recently, Lingui got some great improvements regarding RSC support. We
also have a new separate article [Lingui with React Server
Components](https://lingui.dev/tutorials/react-rsc) and sample projects
that show how to use Lingui for i18n in Next.js project with App Router
(by @vonovak).
So I think it would be great to add Lingui to this list.
### How?
Add a new list item.
Co-authored-by: Sam Ko <sam@vercel.com>
Fix: Correct URL generation in sitemap to use product.id
- Updated sitemap function to correctly use product.id for URL
generation instead of id.
- Ensured each product's URL is accurately reflected in the sitemap
output.
I have added to all packages that are imported from node, the `node:`
and I have reordered the imports, first the `node:` ones to make it more
readable, as well as only importing the necessary functions.
I ran a `node --prof` before and after the modifications and it seems to
be more optimal now than before.
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
Bump ci-info to 4.0.0, deleted from devDevpendecy: @types/ci-info , now
the dependency brings the types.
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
To reduce the number of files cloned during `create-next-app`, this PR
shifts the SVG assets placed in the `public/` folder to instead by
consumed from the Next.js site.
Since these are SVG files (vector images), the Image component does
_not_ optimize them with image optimization. Image optimization only
applies to raster images (like `.png` or `.jpg`). This means it's
effectively similar to using the `unoptimized` prop on the `Image`
component, which means you don't need to add `remotePatterns` to
`next.config.js` – which would be midly annoying for the
`create-next-app` starter.
I also renamed `file-text.svg` to `file.svg` so the URL is shorter.
These assets will be live on .org any minute now.
### What?
* adds next-build-test to the workspace
* use multiple turbo-tasks root tasks to be more realistic
* add tracing support
* run pages in order
* add development mode with HMR
* updates for RcStr
### Why?
### How?
We either need GCC >= 4.9 or we need to link with libatomic:
https://github.com/microsoft/mimalloc/issues/443
Unfortunately, manylinux2014-cross ships with GCC 4.8.5:
https://github.com/rust-cross/manylinux-cross/blob/main/manylinux2014/aarch64/Dockerfile#L71
We already appear to override the compiler toolchain in CI for x86_64 to
use clang (which is why mimalloc works there), so let's go ahead and do
that here too. This at least means we're using the same compiler across
both architectures.
I'm leaving the aarch64-musl codepath the same (using gcc) because (1)
we don't use mimalloc there yet and (2) it's a bit harder for me to test
as thoroughly.
# Testing
## Local Compilation
Run bash inside the docker image (I also had to install rosetta2 inside
my Linux VM, as this is an x86_64 image used for cross-compilation to
aarch64):
```
podman run --platform=linux/amd64 -t -i ghcr.io/napi-rs/napi-rs/nodejs-rust:stable-2023-09-17-aarch64 bash -l
```
```
git clone https://github.com/vercel/next.js.git --filter=blob:none --branch canary --single-branch
cd next.js
git checkout 6ae9828cce
```
Run the build locally:
```
apt update &&
apt install -y pkg-config xz-utils dav1d libdav1d-dev &&
export JEMALLOC_SYS_WITH_LG_PAGE=16 &&
rustup show &&
rustup target add aarch64-unknown-linux-gnu &&
npm i -g "@napi-rs/cli@${NAPI_CLI_VERSION}" &&
export CC_aarch64_unknown_linux_gnu=/usr/bin/clang &&
export CFLAGS_aarch64_unknown_linux_gnu="--target=aarch64-unknown-linux-gnu --sysroot=/usr/aarch64-unknown-linux-gnu" &&
cd packages/next-swc && npm run build-native-release -- --target aarch64-unknown-linux-gnu &&
llvm-strip -x native/next-swc.*.node &&
objdump -T native/next-swc.*.node | grep GLIBC_
```
Sanity check that the result is an aarch64 binary
```
$ file native/next-swc.linux-arm64-gnu.node
native/next-swc.linux-arm64-gnu.node: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped
```
## Verifying the binary works
Copy the next-swc binary into a copy of shadcn-ui I have sitting around:
```
podman cp 4e8f61b17965:/next.js/packages/next-swc/native/next-swc.linux-arm64-gnu.node ~/ui/node_modules/.pnpm/file+..+nextpack+tarballs+next-swc.tar/node_modules/@next/swc/native/next-swc.linux-arm64-gnu.node
```
and then try running the dev server and loading pages from it in the
browser:
```
pnpm --filter=www dev --turbo
```
## In CI
https://github.com/vercel/next.js/actions/runs/9523143080/job/26254016137
This handles the case where a middleware rewrite causes us to fail to
resolve the correct dynamic route params for an action sent to a
prerendered ISR path since the matched path wouldn't be the original
source path like we expect and instead is the prerendered path so we
need to parse the params out instead.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
Sometimes, probably when you have a lot of tests, I've noticed that some
tests are failing with the error `browserContext.route: Test ended`.
After some debugging I found that `page.route(…)` needs to be awaited
before continuing.
### Why?
So that Playwright works correctly with the `next` fixture.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
- remove fail fast so we can get a full picture of what's failing
- remove alerting/retrying to existing job
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Users that experiment with PPR and might have seen #61798, or #62703, or
most recently #65483, may try the `__nextppronly=1` query param to debug
the static shell. This will lead to the following uncaught error and
blank page:
<img width="1045" alt="static shell debugging hydration error"
src="https://github.com/vercel/next.js/assets/761683/ed382d97-82ae-4a23-9930-bb4d4419e88e">
It might not be immediately obvious that javascript must be disabled to
see the static shell. To improve the DX in this scenario we can omit the
bootstrap script to skip hydration, and thus prevent the error. Then
debugging the static shell works even without disabling javascript in
the devtools.
<img width="1045" alt="static shell debugging without hydration"
src="https://github.com/vercel/next.js/assets/761683/57f6cb88-f5b4-473f-963f-7fda8c8e7f00">
In addition, we should add the closing body and html tags to the shell
so that a valid HTML document is returned.
`node_modules` gets ignored when deployed unless explicitly allowed, and
the regular install command will clobber what was in there.
This allowlists the `node_modules` directory and copies it into a new
folder, runs the install command, and then merges the patched
`node_modules` in so the patched modules are available in the test.
