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>
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.
Bump conf to 13.0.0
I have changed the `moduleResolution` in tsconfig to `bundler` because
apparently the new versions of that dependency does not work with
`moduleResolution:node`, issues where it explains it: [issues in
conf](https://github.com/sindresorhus/conf/issues/181)
---------
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
## 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>
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>
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