Previously the code used in both edge and node runtimes used _almost_ the same code. This unifies the two into the base server implementation while also preserving the specific case handled by the split.
This also moves the `/_next/data` route matching to a cached value to prevent it from creating the `RegExp` on every request evaluation.
Adding a default app router not-found error page in production. We introduced a custom global not-found page if you have `not-found.js` file under app directory. Next.js will still routed you to default pages 404 if there's no routes matched when you don't have a custom `not-found.js`.
This PR creates a default layout (only having `html` and `body`) and will use the default not-found component as children to build a default 404 page for app router, and server will route to that page when there's any app router pages existed. This will also fix the hmr issue that when you hit a pathname doesn't exist, nextjs will compile `/_error` for you which is not expected, now we're using `/not-found` instead
Closes NEXT-1359
for internal:
https://vercel.slack.com/archives/C03S8ED1DKM/p1691700057242999
### Problem
- The existing [`redirect()`
function](https://nextjs.org/docs/app/api-reference/functions/redirect)
can't control the status code.
- The existing [`redirect()`
function](https://nextjs.org/docs/app/api-reference/functions/redirect)
returns a 307 HTTP redirect response while it returns a 308-equivalent
meta tag `<meta http-equiv="refresh" content="0;url=/foo"/>` in
streaming response (e.g., suspense boundary), making the behavior
inconsistent.
### Solution
Adding a new `permanentRedirect()` function and changing the meta tag
default accordingly.
| func | HTTP status | meta tag |
|---|:---:|---|
| `redirect()` | 307 | `<meta http-equiv="refresh"
content="1;url=/foo"/>` |
| `permanentRedirect()` | 308 | `<meta http-equiv="refresh"
content="0;url=/foo"/>` |
ref.
https://developers.google.com/search/docs/crawling-indexing/301-redirects
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
add if statement, because typescript throws error: revalidatePath require `string`, but `searchParams.get('path')` returns `string|null` type
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This replaces the existing recursive directory reading beheviour with a more efficient implementation. Rather than previously doing actual recursion with the function calls to go deeper into each directory, this has been rewritten to instead use a while loop and a stack. This should improve memory usage for projects with very deep directory structures.
The updated design that performs directory scanning on all directories found at each layer, allowing more filesystem calls to be sent to the OS instead of waiting like the previous implementation did.
**Currently the new implementation is about 3x faster.**
### What?
fix the paths for app pages with route groups (e. g. `(dashboard)`)
Closes WEB-1463
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
## What?
This PR fixes issue #54304. As discussed in the issue it was suspected that the values of weights were not being sorted correctly. The weights were being sorted in lexicographical order.
In order for Google fonts to work, Google Fonts need the values of weights present in the url in sorted order.
Due to this the url which was being generated for Google Fonts which had a value of "1000" in weight was giving an error and the font was not working.
## Why I Think This Solution Works?
Let's assume that we have an object named axes with the property named named "wght" which will have the value of weights as following:
```
const axes = {
wght: ["100", "200", "300", "400", "500", "600", "700", "800", "900", '1000']
}
```
Let's create another variable named "display" with the value set as "swap" and create another variable named "fontFamily" with the value as "DM Sans" (this is the font which was being used in the issue).
```
const fontFamily = "DM Sans";
const display = "swap";
```
If we call the function using them
```
const FONT_URL = getGoogleFontsUrl(fontFamily, axes, display);
console.log("The font url is: ", FONT_URL)
Output Will Be:
The font url is: https://fonts.googleapis.com/css2?family=DM+Sans:wght@100;1000;200;300;400;500;600;700;800;900&display=swap
```
It will give the incorrect value which was shown in the issue.
If you see at line number 56 there was no comparison function passed in the sort function which is what was suspected earlier and it was sorting the values lexicographically.
Create another variable inside the function above line 54 where we are updating the value of "url" variable.
```
const variantValues = variants.map((variant) => variant.map(([, val]) => val).join(','))
console.log("Variant Values: ", variantValues)
Output Will Be:
Variant Values: ["100", "200", "300", "400", "500", "600", "700", "800", "900", "1000"]
```
Now call the function again with the same values you will see the values in the correct order but as soon as you call "sort" function it will give you incorrect sorted values which is what is happening in the "url" variable.
```
const variantValues = variants.map((variant) => variant.map(([, val]) => val).join(',')).sort()
console.log("Variant Values: ", variantValues)
Output Will Be:
["100", "1000", "200", "300", "400", "500", "600", "700", "800", "900"]
(As you can see the values are sorted incorrectly)
```
There was one case when I implemented this solution. When "ital" is also passed then the values are in "ital,wght" format and because of it the sorting was giving incorrect result for this case.
Let's update the "axes" variable which we made previously to contain these values:
```
const axes = {
wght: ["500","300", "400"],
ital: ["0","1"]
}
```
Now when we run the function it gives us the result as:
`
https://fonts.googleapis.com/css2?family=DM+Sans:ital,wght@0,500;0,300;0,400;1,500;1,300;1,400&display=swap`
Where as the expected result was:
`https://fonts.googleapis.com/css2?family=DM+Sans:ital,wght@0,300;0,400;0,500;1,300;1,400;1,500&display=swap`
So, I rewrote the "sort" function to also handle this case.
## What Did I Do To Fix It?
I passed the comparison function inside the "sort" function which was being to ensure that the elements are compared as integers, and thus the sorting will be done numerically.
Which gave me the correct output as url:
`https://fonts.googleapis.com/css2?family=DM+Sans:wght@100;200;300;400;500;600;700;800;900;1000&display=swap`
With values being sorted correctly and if you visit the link you will see the response instead of the error.
Any thought's or suggestions would be greatly appreciated.
Noticed there were two cases in `next-server.ts` that leverage `this as any` to call functions defined only in next-dev-server.
This change ensures the types are correct, which is useful for refactoring, e.g. renaming the function in `next-dev-server` would cause the original code to break unexpectedly.
https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations
Some of the code blocks where I only specified TS code snippets aren't
working with JS as well (when there are no types). I think I might have
incorrectly assumed you could leave those out. So added the JS snippets
in here (same code, just different file names).
This fixes our caching for the docker builds as they were missing inputs
the other jobs had also enables caching the rust target cache which
improves build times when only changing our package and the lockfile
isn't invalidated.
Tested here https://github.com/vercel/next.js/actions/runs/5987764387
### What?
This PR adds the `cms-sitecore-xmcloud` example.
Sitecore XM Cloud is a headless CMS platform that empowers content editors to manage content, layout, and structural aspects of web pages. The Sitecore JSS framework connects frontend JavaScript applications to the XM Cloud API, allowing retrieval of content and presentation layout information.
Sitecore JSS for Next.js integrates Next.js with Sitecore JSS, offering a structured approach to connect a Next.js application to XM Cloud. The `cms-sitecore-xmcloud` example, derived from the Sitecore JSS initializer, showcases the frontend application exclusively, omitting backend implementation details.
### Why?
While Sitecore offers detailed documentation for creating XM Cloud projects and JSS applications, existing starter templates often combine frontend and backend configurations. The `cms-sitecore-xmcloud` example focuses solely on the frontend application and includes environment variable examples to establish a connection with XM Cloud, eliminating the need for a .NET-compatible machine.
### How?
For comprehensive guidance on setting up an XM Cloud site and JSS application, refer to Sitecore and Vercel documentation. The `cms-sitecore-xmcloud` example is created using the Sitecore JSS initializer, integrating Next.js and SXA (Sitecore Experience Accelerator) add-ons. Further documentation can be found at:
- [Deploying to Vercel](https://doc.sitecore.com/xmc/en/developers/xm-cloud/walkthrough--deploying-your-front-end-application-to-vercel.html)
- [Documentation (Experience Platform)](https://doc.sitecore.com/xp/en/developers/hd/210/sitecore-headless-development/sitecore-javascript-rendering-sdk--jss--for-next-js.html)
- [Documentation (XM Cloud)](https://doc.sitecore.com/xmc/en/developers/xm-cloud/sitecore-javascript-rendering-sdk--jss--for-next-js.html)
- [Documentation (Create an XM Cloud project from a starter template)](https://doc.sitecore.com/xmc/en/developers/xm-cloud/create-an-xm-cloud-project-from-a-starter-template-in-the-xm-cloud-deploy-app.html)
Co-authored-by: Steven Tey <28986134+steven-tey@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
I don't believe these benches were intended to run as part of the monorepo `dev` task. This renames the `dev` task to `dev-application` similar to `build-application` (which I assume was aliased for a similar reason)
Fixes#54592
When I was working on #54199 , if the file path is wrong the next app build error only shows "can't read file from ...", it took me hours to figure out where it actually fails in next build command. Adding an prefix for the error message so that could identify it easier.
Also clean up other unused comments and incorrect named variables
This implements the same cleanup logic used for start-server and render-workers for the workers used during build.
It's more of a contingency as we do call `.end()` on the worker too.
Fixes#45508
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
## Implementation
Base on #54530, we're implementing a `optimize_barrel` transform to
optimize barrel files to only export the names we need. If the
transformed file isn't a "barrel file", we just re-export the names from
it without any transformation.
Take `lucide-react` as an example, with #54530 we are able to transform
```js
import { IceCream } from 'lucide-react'
```
to
```js
import { IceCream } from '__barrel_optimize__?names=IceCream!=!lucide-react?__barrel_optimize_noop__=IceCream'
```
And then, we apply that new request with a new Webpack module rule to
use the SWC loader with option `optimizeBarrelExports: ['IceCream']`,
which eventually got passed to this new `optimize_barrel` transform and
does the optimization.
## Notes
We'll have to add a new `getModularizeImportAliases` alias list to map
`lucide-react` to the ESM version, as we have the `['main', 'module']`
resolve order for the server compiler. Otherwise this optimization
doesn't work in that compiler.
There's no e2e test added because it's already covered by the
`modularize-imports` test as we removed the default `lucide-react`
transform rules and it still works.
We'll need to test other libs before migrating them to the new
`optimizePackageImports` option.
---
Closes#54571, closes#53605, closes#53789, closes#53894, closes
#54063.
This PR is a larger change to documentation to make the following
updates:
- Deconstructs [Server
Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions)
into "Forms and Mutations" and an API reference
- Removes content in place of future React API documentation pages
- Removes outdated [Building
Forms](https://nextjs.org/docs/pages/building-your-application/data-fetching/building-forms)
docs from the Pages Router and adds conditional content for both routes
in "Forms and Mutations"
- Adds TypeScript code blocks to API Routes page, recommends Route
Handlers for isomorphic signatures.
- Updates `revalidatePath` and `revalidateTag` docs to have a Server
Actions example.
---------
Co-authored-by: Delba de Oliveira <32464864+delbaoliveira@users.noreply.github.com>
Before:
```
Error: `export const config` in /vercel/path0/src/app/api/route.js is deprecated. Please change `runtime` property to segment export config. See https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config
```
After:
```
Error: `export const config` in /vercel/path0/src/app/api/route.js is deprecated:
- Change `config.runtime…` to `export const runtime = "edge"`
- Change `config.regions…` to `export const preferredRegion = ["us-east-1"]`
Visit https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config for more information.
```
The values proposed in Change.. are the actual ones from the customers, they can just copy paste.
Closes NEXT-1560
Hello!
I recently tried to cache the `.next/cache` directory in a GitHub action following what was said in the documentation and realized that hashing the source files didn't work properly.
This problem also occured in [next-cache](https://github.com/jongwooo/next-cache) and was fixed by [this PR](https://github.com/jongwooo/next-cache/pull/17).
This PR simply changes the example from the documentation to apply the same fix (stop using brackets in the patterns passed to `hashFiles`).
Hope it helps!
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide
This ensures we don't pass through the signal field when revalidating a
fetch as that can be delayed and we don't want to abort the
revalidation.
Closes: https://github.com/vercel/next.js/issues/54045
### What?
* add support for middleware manifest and edge adapter for pages API
routes
* improve the error reporting a tiny bit
### Why?
### How?
Closes WEB-1428
When `fallback: false` is set and you visit a dynamic segment (e.g. `/[slug]`), the router server was getting stuck in a `x-no-fallback` loop and eventually would fail because it was matching the output at `check_fs` before attempting to resolve dynamic routes in the `check: true` block.
Closes NEXT-1557
This PR adds missing parameters to the `useSelectedLayoutSegment` & `useSelectedLayoutSegments` hooks since they take *optional* `parallelRoutesKey`.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
