## What?
This PR adds an option to use `sass-embedded`.
## Why?
For large projects sass-embedded improves SCSS compilation time by over
50%.
See also https://github.com/vercel/next.js/discussions/36160
## How?
Added a sassOption `implementation` to configure the sass-loader which
Sass implementation to use.
See also https://www.npmjs.com/package/sass-loader#implementation
I think this a similar approach to what is done for `additionalData`.
## Additional notes
In order to support `sass-embedded`, `sass-loader` is upgraded to
12.6.0.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
Writes the async flag to the client reference manifest to support ESM
externals in app dir.
The `app-ssr` context can't have esm externals as that might cause a
module to be async in ssr but not on the client.
Closes PACK-2967
Fixes#64525
### What
app-dir `metadata.test.ts` is pretty big and includes a lot of erroring
tests and navigation tests. Breaking them into smaller suites to avoid
the erroring on effect on others.
- metadata
- metadata-navigation
- metadata-thrown
Moved the metadata testing utils into `next-test-utils` for sharing
purpose.
Moved the hmr test to the bottom to avoid flakyness.
### What
Remove the duplicated `setup-hydration-warning`
### Why
we already handling the warning message appending in error dialog, no
need to intercept it again.
### What?
cache wasn't well reused since all client chunks depend on the client
shared chunk, which had a different name for every page.
This fixes that and allows caching of all client component chunks
### Why?
Since `jest.autoRun` in `.vscode/settings.json` is deprecated, this PR
replaces it with an equivalent setting using the recommended migration
guide.
> Starting from v6.1.0, if no runMode is defined in settings.json, the
extension will automatically generate one using legacy settings
(autoRun, showCoverageOnLoad). To migrate, simply use the "Jest: Save
Current RunMode" command from the command palette to update the setting,
then remove the deprecated settings.
x-ref:
https://github.com/jest-community/vscode-jest/blob/master/README.md#autorun
When performing a redirect() with an absolute path, action-handler
attempts to detect whether the resource is hosted by NextJS. If we
believe it is, we then attempt to stream it.
Previously we were not accounting for basePath which caused absolute
redirects to resources on the same host, but not underneath the
basePath, to be resolved by NextJS. Since the resource is outside the
basePath we resolve a 404 page which returns back as `text/x-component`
and is thus streamed back to the client within the original POST
request.
This PR adds a check for the presence of the basePath within absolute
redirect URLs. This fixes the above problem.
fixes#64413fixes#64557
---------
Signed-off-by: Chris Frank <chris@cfrank.org>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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
