## 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
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
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.
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>
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>
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.
https://github.com/vercel/turbo/pull/8165 introduced plugins that
operate before resolving occurs, meaning that plugins like
`InvalidImportResolvePlugin` which never use the initial resolve result
and report issues can avoid that work.
Test Plan: `TURBOPACK_DEV=1 TURBOPACK=1 pnpm test-dev
test/development/acceptance-app/invalid-imports.test.ts`
Upgrade devdependecy commander to latest versio.
Now in command, the optional argument is with [] and the required
argument is with <>.
---------
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
### What?
This modifies the static generation store to instead store a `url`
object with the `pathname` and `search` properties. This corrects the
previous behaviour which used the variable `urlPathname` which had
ambiguous meanings as it technically contained the search string as
well, not just the pathname.
In cases during the app render, this still grabs the contents of
`url.pathname + url.search` (where `url.search` always has a leading `?`
if it has any query parameters, [see the
docs](https://developer.mozilla.org/en-US/docs/Web/API/URL/search)) so
that it emulates the current behaviour. This allows more specific access
though, where now additional parsing can be eliminated which had to
strip the query string off of the `urlPathname` in a few places, and
more worrisome, still accidentally contained the search string causing
errors.
### How?
This requires an upstream fix (#64088) which corrected a bug with the
store access which had caused some previous test failures (accessing
`store.url.pathname` was throwing as `store.url` was undefined on the
wrong return, check the upstream PR for more details on that).
This also changes out usage of `pagePath` with `route`, and lets it be
the fallback (for debugging and error messaging). During static
generation, we will provide a value for the page being rendered that's
correlated to the particular file on the filesystem that the route is
based on:
```
// rendering app/users/[userID]/page.tsx
page: /users/[userID]
pathname: /users/1, /users/2, etc
```
The `route` is used only for debugging, such as when
`generateStaticParams` incorrectly calls `headers()`.
This also moves the pathname from the `staticGenerationStore` into the
`requestStore`, as it's tied to a given request.
Closes NEXT-2965
Closes [#66650](https://github.com/vercel/next.js/issues/66650)
Closes NEXT-3520
### What?
- Make Link not throw during prefetch if it received an invalid `href`
(see [#66650](https://github.com/vercel/next.js/issues/66650))
- Throw in dev mode if an invalid link was passed to `router.prefetch`
-- this matches current prod behavior
- (previously, we'd immediately exit out of `router.prefetch`, so the
user would see no indication that this'd fail in prod)
### Why?
If an invalid URL was passed to `<Link>`, the whole app would crash and
show "A client-side exception occurred". A failed prefetch should not
bring down the whole app.
Note that This preserves the current behavior of explicit
`router.prefetch(url)` throwing an error if `url` is invalid. We may
want to adjust this in the future, but that could be considered a
breaking change, so I'm leaving it out for now. This only affects
`Link`, which was intended to catch any errors thrown from
`router.prefetch`, but that bit was accidentally broken.
Upgrade devDependecy prettier-plugin-tailwindcss to the latest version
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
### What
Use `addDependency` to track the file path passed to
`next-metadata-route-loader`
NOTE: We cannot apply the `next-metadata-route-loader` directly to the
metatda convention source files, since the json file could be processed
by json loader (Related previous fix#62615)
### Why
Previously when we passed down the file path as argument to the loader,
which sort of breaking the caching of webpack as the actual resource
path is string, it's not tracked as a dependency. This change fixed the
bad caching issue of static metadata routes. Based on the above reason
we use `addDependency` here to track the dependency change
Closes NEXT-3521
Closes#65755
### What
Skip adding trailing slash for file pattern like same origin urls
### Why
Fixes#66635
Next.js will not append trailing slash for file like pattern urls when
`trailingSlash` is enabled. This PR aligns the behavior of the metadata
trailing slash appending with next-server route handling.
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
To allow us to incrementally adopt more comprehensive linting rules,
this pull request disables the previous behaviour of failing CI when any
warnings were discovered. Instead, this modifies the previous warnings
to be errors which will preserve the previous linting behaviour. As we
enable new lint rules, they can be added as warnings which will gently
nudge us towards fixing in related pull requests.
As discussed this adds handling to timeout at a max of 500ms for fetch
cache request and retries a max of 3 times due to network instability.
This also adds cache service tests and fixes a case we've been trying to
track down where we were seeing `undefined` cache URL values which made
debugging fetches tricky.
To assist with the development and testing of the new partial
prerendering (PPR) paradigm, this introduces a stop-gap solution to let
us verify issues with pages in preview and production environments if
enabled. When a Next.js app is built and ran with the
`__NEXT_EXPERIMENTAL_STATIC_SHELL_DEBUGGING=1` environment variable,
pages that have PPR enabled in production and preview environments can
have only their static shell served when accessed with a
`?__nextppronly=1` query parameter.
If your project is not using PPR, it will not change anything. If a page
is accessed in production or development with the query parameter but
PPR is not enabled, it will not change anything. Tests have been added
to validate that going forward.
### What
Optimizing the static generation for dynamic metadata routes
If you're not using `generateSitemaps()` or `generateSitemaps()`, you
don't need to change any file conventions.
If you're using multi sitemap routes, make sure the returned `id`
properties from `generateSitemaps()` don't need to contain `.xml`, since
we'll always append one for you.
Analyzing the exports of metadata routes and determine if we need to
make them as dynamic routes.
### Why
Previously, users are struggling with the multi routes of sitemap or
images.
For sitemap, the `.xml` extension in url doesn't get appended
consistently to the multi sitemap route between dev and prod.
For image routes, the generated image routes are always dynamic routes
which cannot get static optimized.
The reason is that we need to always generate a catch-all route (such as
`/icon/[[...id]]` to handle both single route case (e.g. without
`generateImageMetadata`, representing url `/icon`) or multi route (e.g.
with `generateImageMetadata`, representing url `/icon/[id]`), only
catch-all routes can do it. This approach fail the static optimization
and make mapping url pretty difficult as parsing the file to check the
module exports has to be done before it.
#### Benifits
For image routes urls, this approach could help on static generation
such as single `/opengraph-image` route can be treated as static, and
then it can get static optimized if possible.
**Before**: `/opengraph-image/[[...id]]` cannot be optimized
**After**: single route `/opengraph-image` and multi-route
`/opengraph-image/[id]` are both possible to be statically optimized
For sitemap, since we removed appending `.xml` for dynamic routes, it’s
hard for users to have `/sitemap.xml` url with dynamic route convention
`sitemap.js` . But users desire smooth migration and flexibility.
**Before**: In v15 rc we removed the `.xml` appending that `sitemap.js`
will generate url `/sitemap` makes users hard to migrate, as users need
to re-submit the new sitemap url.
**After**: Now we'll consistently generate the `.xml`. Single route will
become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`.
It's still better than v15 as the urls generation is consistent, no
difference between dev and prod.
Here's the url generation comparsion
#### Before
All the routes are dynamic which cannot be optimized, we only had a
hacky optimization for prodution build multi-routes sitemap routes
| | only default export | `export generateImageMetadata()` | `export
generateSitemaps()` |
| -- | -- | -- | -- |
| opengraph-image.js | /opengraph-image/[[...id]] |
/opengraph-image[[...id]]/ | /opengraph-image/[[...id]] |
| sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev:
`/sitemap/[[...id]]` prod: `/sitemap/[id]` |
#### After
Most of the single route will are to get statically optimized now, and
the multi-routes sitemap are able to get SSG now
| | only default export | `export generateImageMetadata()` | `export
generateSitemaps()` |
| -- | -- | -- | -- |
| opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - |
| sitemap.js | /sitemap.xml | - | /sitemap/[id].xml |
Next.js will have less overhead of mapping urls, we can easily multiply
the urls generation simply based on file conventions.
x-ref: feedback from #65507Closes#66232
### Why?
Importing `tailwind/tailwind.css` is not possible right now with
turbopack, and there's no reason it needs to be marked as external.
### How?
Closes PACK-3013
Fixes#64837
### What
Remove creating client proxy for each ESM export, instead for ESM we
create a CJS module proxy for itself and access the property with export
name as the actual export.
### Why
`proxy` is the module proxy that we treat the module as a client
boundary.
For ESM, we access the property of the module proxy directly for each
export.
This is bit hacky that treating using a CJS like module proxy for ESM's
exports,
but this will avoid creating nested proxies for each export. It will be
improved in the future.
Notice that for `next/dynamic`, if you're doing a dynamic import of
client component in server component, and trying to access the named
export directly, it will error. Instead you need to align the dynamic
import resolved value wrapping with a `default:` property (e.g. `{
default: resolved }`) like what `React.lazy` accepted.
Revert #57301Fixes#66212
x-ref:
[slack](https://vercel.slack.com/archives/C04DUD7EB1B/p1716897764858829)
Update devdependecies tar and type.
I have only imported the necessary function, maybe it is a little
unverbose, we can use instead of ‘x’ => ‘extract’.
---------
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
During navigations, the `FlightDataPath` property from the server
response can be an array if there are multiple parallel routes (eg,
`children` and `slot`). When we apply server response to the router
cache, we might call `applyFlightData` for each segment path, which will
copy existing cache values and insert new ones depending on what
changed.
However, the `existingCache` argument that we pass to this function is
the cache at the start of the navigation. That means subsequent calls to
`applyFlightData` will reference the cache _before_ updates are made to
it. This will cause it to erroneously think it needs to lazy fetch for
missing data.
<!-- 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 #
-->
When checking which segment(s) need to be refreshed, we currently
compare the current page URL with the segment's refresh marker.
We should inspect the `mutable.canonicalUrl` value first since that's
the URL we're changing to, followed by `state.canonicalUrl` as a
fallback (indicating that there's no URL change pending). This is
because the server action handler will receive a redirect URL prior to
`location.pathname` being updated, so the router will incorrectly think
it needs to refresh the data for the page we're going to.
Closes NEXT-3500
This flag remained experimental because the IPC implementation didn't
play nicely with requests containing large payloads, due to it being
stringified as GET parameters. This branching logic also poses
challenges for some upcoming work related to detecting IO.
This removes the handling for the
`experimental.staticWorkerRequestDeduping` flag which we can revisit in
the future with a sounder approach. This also cleans up some of the IPC
server utilities as it wasn't in use anywhere else.
<!-- 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 #
-->
This PR fixes the same case mention in #66464. Instead of collecting all
values eagerly, here we merge fields (on any level of depth) of the same
value and skip methods. For example:
```ts
foo.bar
foo.bar.baz
qux.fn()
```
Previously we're (wrongly) collecting `[foo.bar, foo.bar.baz, qux.fn]`,
and now it will be just `[foo.bar, qux]`.
Merging of fields is critical for collecting methods correctly because
in theory we can't tell if an object member is a method or not:
```ts
data.push.call(data, 1)
// or inside a function that does the same:
doPush(data.push, data)
```
If we don't merge fields we'll collect `[data.push, data]` which still
fails.
### What & Why
Fixes NEXT-3498
Fixed loading shows up and disappear during client navigation, when you
defined `prefetch` is enabled and slow `generateMetadata` is defined. In
#64532, where in layout-router, we removed the place of infinite
suspense, adding it back so that the app can still remain suspensy
during navigation.
#### Behavior before fix
Prefetch -> Link Navigation -> Show `loading.js` -> RSC payload fetched
(no page content) -> the page content will display later when the
promise is resolved
#### Behavior after the fix
Prefetch -> Link Navigation -> Show `loading.js` -> RSC payload fetched
-> suspensy page content still triggering `loading.js` -> display the
resolved page content when the promise is resolved
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
