Remove the experimental `serverActions` flag
Co-authored-by: Shu Ding <3676859+shuding@users.noreply.github.com>
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
We already had `domains` as "not recommended" but this PR marks it as "deprecated" and prints a warning if its detected.
I also updated all examples to switch from `domains` to `remotePatterns`.
### Story
Since we introduced `ImageResponse` into `next/server` export, there're a few libraries relying on `next/server` that accidentally ended up with bundling og image into the bundle. As og package is quite large that could easily raise the size concern for middleware, edge runtime routes.
### Struggles
We've done optimizations. The tree-shaking strategies are tricky, we tried modularize imports and also optimize cjs require/exports to make sure you're not including og package into bundle if it's not being used. However, it's still not 100% can handle all the bundle optimization cases, such as `import {..} from "next/server.js"` could also ended up with the cjs bundle that failed the tree-shaking.
### Move on
So we decide to move og `ImageResponse` into a separate export `next/og`
Closes NEXT-1660
## History
We used to pass `onLoad` through directly to the underlying img so `onLoadingComplete` was introduced in order to handle the case when `placeholder="blur"` was used and `onLoad` would trigger before the placeholder was removed.
We have since changed the behavior of `onLoad` so that it acts the same as `onLoadingComplete` and therefore `onLoadingComplete` is no longer needed.
## What is this PR doing?
This PR marks `onLoadingComplete` as deprecated in favor of `onLoad`. In the future, we may remove `onLoadingComplete`.
Upgraded dotenv to v16. Breaking changes are:
- Multiline parsing support
- Support inline comments
- Backtick support
[See their changelog](https://github.com/motdotla/dotenv/blob/master/CHANGELOG.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
### What?
BREAKING CHANGE: Bump the minimum required Node.js version.
### Why?
Node.js 16 has reached end-of-life in September.
Bumped to `18.18.2` since it contained some security-related patches: https://nodejs.org/en/blog/vulnerability/october-2023-security-releases
### How?
Bumped `engines` where needed, upgraded the workflows.
This will allow us to remove quite a few polyfills, I'll open separate PRs for those.
Fixed a typo -
docs/04-architechture/supported-browsers.mdx
Changes(s) made -
Fixed a typo for improving clarity
[includes -> include]
'your dependencies includes' -> 'your dependencies include'
Please review and merge it.
Based on feedback from #56603, the `/` can be interpreted as file paths instead of filename separators / delimiters. We'll change them to use pipes `|` instead.
Fixed the example functions in the documentation to use `async` in order to use `await` within the function body.
Co-authored-by: Michael Novotny <446260+manovotny@users.noreply.github.com>
### What?
Update documentation on dynamic routing to clarify the use of segment names within file names, rather than referring to them as "folder names".
### Why?
The original documentation used the example term `folderName` when it was referencing dynamic segment names within filenames. The paths being described here are file names but not folders, and end in a file extension. This could confuse readers and developers, especially those new to Next.js, leading to potential misunderstandings and misconfigurations. Perhaps folderName was a relic of a different example wrapping a folder name to do a nested path or other configuration? But here it seems out of place.
### How?
- Reviewed the provided documentation sections on dynamic routing.
- Replaced references to "folderName" with a different term "segmentName".
- Ensured the examples provided in the documentation correctly showcase the use of segment names within filenames.
IMO there is not enough of an indicator that client components render on the server on full page loads towards the top of the documentation page. I've seen plenty of experienced devs totally miss this critical info and get stuck on a problem due to a lack of understanding. Putting at least some kind of indicator above the fold would help with that.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
When trying to update my own website to use App Router, I found the current Next.js Docs were missing specifics to get it working (most notably, no mention of `pageExtensions`). Coupled with community feedback, we decided to revisit and rework the entire page.
The page has been walked through and tested on brand new create-next-app projects for both App and Pages Routers to ensure completeness.
Closes [DX-2095](https://linear.app/vercel/issue/DX-2095/improve-nextjs-mdx-docs)
Rendered pages while running locally, in case they are more helpful in seeings the changes and different between routers.
### App Router
### Pages Router
The link to the useSearchParams ref within the File Conventions > layout.js page currently links to the useParams ref, which is wrong and may lead to confusion as the useParams and useSearchParams APIs operate differently.
TypeScript 5.2 now supports `Response.json` (https://github.com/microsoft/TypeScript/issues/52841). That means, if we just need to return a JSON `Response`, we no longer need to import `NextResponse`. This PR updates all such instances in the documentation to use `Response.json`.
This will be the recommended way of passing extra arguments to a Server Action. A couple of reasons behind:
- This is better than putting a hidden `<input hidden value={userId}/>` because that will appear in the SSR'd HTML as full text and cannot be encoded. With `.bind`, we can handle that in the future.
- This is better than event callbacks `onSubmit={(e) => { await updateUser(userId, e.target.formData) }}` as this supports progressive enhancement.
- This is better than re-creating a new action `action={async (formData) => { "use server"; return updateUser(userId, formData) }}` as inlined `"use server"` only works in Server Components.
In "app/actions.ts" the function is named like create(), but in "app/add-form.tsx" file "createTodo" function is imported and used. This is related to TypeScript examples, .js files are ok.
### What?
Renamed a function.
### Why?
There are two example files in docs ([Error Handling](https://nextjs.org/docs/app/building-your-application/data-fetching/forms-and-mutations#error-handling) section) and the `app/add-form.tsx` is importing function `create` from `app/actions.ts` by another name (`createTodo`).
### How?
Fixed by renaming function to `createTodo`, to match .js file with the same example.
### Why?
Whenever I run `create-next-app` and reach this question
```
Would you like to customize the default import alias? No / Yes
```
I always have to select "No", because I don't remember what this default import alias here is. [It _is_ documented to be `@/*`](https://nextjs.org/docs/app/api-reference/create-next-app#non-interactive), but the documentation is relatively hidden and not many people know about it – it's also easy to forget.
Even more confusingly, the next question ("What import alias would you like configured?") doesn't have this `@/*` as the default answer, but the user's last choice as the default answer instead (which could be different from `@/*` – making people wonder if Next.js changed their defaults overnight).
I suppose it would be better to just make it clear in the prompt itself, so people with skill issues who happen to forget that default value (like me) can still confidently select "Yes" if they want `@/*`, without having to do "No" and manually type `@/*` again.
### How
```diff
- Would you like to customize the default import alias?
+ Would you like to customize the default import alias (@/*)?
```
as many developers are moving to bun, its a good idea that it also be included as an installation method.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
### What?
Fixing a little mistake in the documentation, where the placement of the `extension` option for `createMDX()` was described as being inside the `options` property:
```ts
const withMDX = createMDX({
options: {
extension: /\.mdx?$/,
```
But it's actually a property of its own:
```ts
const withMDX = createMDX({
extension: /\.mdx?$/,
```
I confirmed that the latter is correct because:
- It solves an issue I was having: Unable to import `.md` files
- On the same docs page, there's another place where it mentions this `extension` option and the code example is correct there
- The option is described in a similar issue, such as https://github.com/vercel/next.js/issues/45431#issuecomment-1410363864
Issue: https://github.com/vercel/next.js/issues/53888
Added "not-found.js" information to error.mdx after the `global-error.js`. Please approve.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
