In the case when the user configured `output: export` and used an API Route Handler that cannot be converted to static, Next.js must throw an error.
fix NEXT-823 ([link](https://linear.app/vercel/issue/NEXT-823))
Ensures that using `searchParams` opts into dynamic rendering.
Fixes#43077
fix NEXT-601 ([link](https://linear.app/vercel/issue/NEXT-601))
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1678838567947919)
Follow-up to https://github.com/vercel/next.js/pull/46317. The issue is
that, if:
- `experimental.clientRouterFilter` is enabled
- `i18n` is enabled with `defaultLocale` set
- Next.js router navigates to a path that (1) is the same as
`defaultLocale` and (2) will be redirected,
then:
- **Expected:** Should hard-navigate to this path without any locale
prefix (and then redirect occurs)
- **Actual:** Hard-navigates to this path with `defaultLocale` prefix,
even though it's not needed (and then redirect occurrs)
### Solution
This PR fixes the above issue by adding `defaultLocale` to `addLocale`
which is passed to `handleHardNavigation`. [`addLocale` skips adding the
locale if `locale` is equal to
`defaultLocale`](02125cf3b1/packages/next/src/shared/lib/router/utils/add-locale.ts (L17)).
### Fixing a bug
- [x] Related issues linked using `fixes #number`
- [x] Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
This PR introduces a new `--tailwind` flag to the `create-next-app` CLI,
to make it easier to bootstrap a Next.js app with Tailwind CSS
pre-configured. This is going to be the **default**. To opt-out of
Tailwind CSS, you can use the `--no-tailwind` flag.
### Why?
Tailwind CSS is one of the most popular styling solutions right now, and
we would like to make it easier to get started.
Currently, the closest you can come to this is by running `pnpm create
next-app -e with-tailwindcss` which will clone the
https://github.com/vercel/next.js/tree/canary/examples/with-tailwindcss
example. But that example is not configured for the App Router. This PR
will let you add Tailwind CSS to both `app/`, `pages/`, and start out
with TypeScript or JavaScript via the CLI prompts.
(Some community feedback
https://twitter.com/dev_jonaskaas/status/1632367991827443713,
https://twitter.com/samselikoff/status/1634662473331617794)
### How?
We are adding 4 new templates to the CLI bundle.
> Note: The styling is not pixel-perfect compared to the current
templates (using CSS modules) to require fewer overrides, but I tried to
match it as close as possible. Here are a few screenshots:
<details>
<summary><b>Current, light</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224733372-9dba86fe-9191-471d-ad9f-ab904c47f544.png"/>
</details>
<details>
<summary><b>Tailwind (new), light</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224733610-038d9d0f-634d-4b69-b5c2-a5056b56760c.png"/>
</details>
<details>
<summary><b>Current, dark, responsive</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224733790-9b4d730c-0336-4dbe-bc10-1cae1d7fd145.png"/>
</details>
<details>
<summary><b>Tailwind (new), dark, responsive</b></summary>
<img
src="https://user-images.githubusercontent.com/18369201/224734375-28384bbc-2c3a-4125-8f29-c102f3b7aa1d.png"/>
</details>
#### For reviewers
This introduces 4 new templates, with a very similar code base to the
original ones. To keep the PR focused, I decided to copy over duplicate
code, but we could potentially create a shared folder for files that are
the same across templates to somewhat reduce the CLI size. Not sure if
it's worth it, let me know. Probably fine for now, but something to
consider if we are adding more permutations in the future.
---
~Work remaining:~
- [x] app+ts
- [x] layout
- [x] dark mode
- [x] media queries
- [x] animations
- [x] app+js
- [x] pages+ts
- [x] pages+js
- [x] prompt/config
- [x] deprecate Tailwind CSS example in favor of CLI
- [x] update docs
- [x] add test
- [x] add [Prettier
plugin](https://github.com/tailwindlabs/prettier-plugin-tailwindcss)
Closes NEXT-772
Related #45814, #44286
Previously when we move to metadata images to custom app routes, when the image files get imported, it matches the `next-image-loader` rule which accidentally generate a static file into media.
This PR appends the metadata reource query to the imported rerource, and then skip in the `next-metadata-route-loader` so they won't get applied by image loader or emit any unexpected assets
In short, this PR adds a 3rd layer to the server compiler. This extra
layer is for marking the modules when re-entering the server layer from
a client component. It is almost identical to the existing server layer
and it should have all the same bundling and runtime behaviors, but it's
still special because it's not allowed to enter the client layer again
from there.
Because of that, we create the extra entry for that new layer when the
client layer compilation finishes in the `finishModules` phase. The new
entry is handled normally as it's in the server layer. But the original
module in the client layer will be compiled specially as special no-op
exports, and will then be connected via the `callServer` wrapper.
fix NEXT-809 ([link](https://linear.app/vercel/issue/NEXT-809)).
Adds support for scrolling based on the [hash
fragment](https://en.wikipedia.org/wiki/URI_fragment) in client-side
navigations for the App Router, mirroring browser behavior.
- `#main-content` → scrolls to `id="main-content"` or
`name="main-content"` property
- `#top` → scrolls to the top of the page, this is a special case in
browsers.
- no hash → default scroll behavior, layout that changed
Fixes NEXT-658
<!-- 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 or adding/fixing 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 #
-->
fixes#44295
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This moves the position of action handling so it can continue page
rendering afterwards. And a `asNotFound` option is added to
`LayoutRouter` to indicate the router to opt into the root not-found
boundary, so not found pages can be programmatically rendered instead of
relying on route mismatching (this is also needed by NEXT-463 later).
Fixes NEXT-467.
Support top-level `robots.[ext]` and `sitemap.[ext]` with dynamic api
routes
* Use isAppRoute to determine api routes and metadata routes as metadata
routes are normalized as `<metadata>/route`
* Normalize path to auto append extension to pathname for sitemap.js and
robots.js
* Add typings `SitemapFile` and `RobotsFile`
* move the normalize logic together, reuse the `absolutePathToPage`.
Changes less when touching both dev-server/hot-reloader and next-server,
use the same utils to handle paths
Closes NEXT-262
---------
This PR implements the route announcer for app directory. It almost uses
the same logic as the route announcer inside pages, with one notable
difference that the inner content node is now inside a shadow root. This
makes sure that it does as little impact as possible, to the
application. This is important as we no longer have the `__next`
wrapper.
Another thing worth mentioning is that the announced title is a global
singleton of the website. It shouldn't be affected by the concept of
layouts, but should be triggered when the router state (not just URL)
changes.
Closes NEXT-208.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Fixes#39330.
I've not added a new test, but extended the existing test instead (and
re-enabled it).
It seems to me that a custom next/image config was not considered during
static generation (which itself uses `next export`?) before. Adding the
config to `renderOpts` in `packages/next/src/export/index.ts` resolves
the issue.
Set the output bundle file path to `/<metadata route>/route.js` to align with other custom app routes, in order to make it easier being handled by app routes in both nextjs and vercel
Generate `/favicon.ico` route when favicon.ico is placed into `app/`.
Still collect favicon metadata image information through
metadata-image-loader but don't emit the file to static dist anymore.
Also collect favicon through metadata routes, and render it as static
routes. Also remove the `hash` we generated before, not needed anymore.
Change metadata static routes rendering process: collect static metadata
assets, read the buffer of the file data and return it in the response.
Closes NEXT-791
This PR adds Zod to the precompiled libraries, and use it to create schemas for the router state tree for validation. In other planned features/changes, Zod will also be used to do run-time data validation.
Fixes NEXT-135.
## Checklist
- [ ] Related issues linked using `fixes #number`
- no related issue exists, happy to open one if desired
- [x] Tests added
- not sure if specific tests are needed? there is an integration test
for environment variables, and Next.js relies a lot on passing
information through environment variables; i'd expect everything to
break if this change broke environment variable handling
- [x] Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
- no new errors, does not apply
### What?
Re-assigning `process.env` substitutes the "magic object" that sets
environment variables at the process level with an ordinary JavaScript
object. This causes environment variables that are set after
`process.env` is re-assigned to not be visible to native add-ons.
See [this Node.js issue][issue] and [this reproduction case][repro] for
details.
[issue]: https://github.com/nodejs/node/issues/46996
[repro]: https://github.com/unflxw/nodejs-process-env-addons-repro
### Why?
In general, paraphrasing the maintainer in the Node.js issue,
re-assigning `process.env` is not a thing you should do. More
specifically, I'm trying to use Next.js' experimental OpenTelemetry
support with AppSignal's Node.js integration, which also uses
OpenTelemetry.
The AppSignal Node.js package sets environment variables in order to
configure a long-running process, which is then launched through a
native add-on. Because of the re-assignment of `process.env` that occurs
early in Next.js' lifecycle process, by the time the AppSignal Node.js
package sets environment variables, it's setting them in an ordinary
JavaScript object that Next.js left in the global `process` object, not
in the magic one created by the Node.js runtime.
This means that these environment variables are not _actually_ being set
for the process at the OS level, and therefore they're also not set for
the native add-on, or for the long-running process it spawns.
### How?
A `replaceProcessEnv` function is implemented that takes an environment
object as an argument, and applies the difference between that
environment object and the current environment to the existing
`process.env` object. This function is used instead of re-assigning
`process.env`.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Move error overlay recovery tests in `ReactRefreshLogBox.test.ts` to a
new file. This is already done for the app router tests, but this does
it for the old router as well. Makes `ReactRefreshLogBox.test.ts` faster
to run.
Support top level static `robots.txt` and `sitemap.xml` as metadata
route in app directory. When those files are placed in top root
directory
Refactored a bit the page files matching logic, to reuse it between dev
server and build
Closes NEXT-267
`test/development/acceptance-app/hydration-error.test.ts` has a lot of tests because I ported all the tests in https://github.com/facebook/react/blob/main/packages/react-dom/src/__tests__/ReactDOMHydrationDiff-test.js. Running all those tests takes a lot of time, and to include all the different cases is overkill.
This PR removes most tests but keeps one test case per type of hydration error, and also one using suspense. This makes more sense, it should only test that all the different hydration error messages are picked up.
fixes https://github.com/vercel/next.js/issues/46549
The docs are wrong for now, this limitation is just in `pages/`, you can
use it anywhere in `app/`.
Since `app/` is still not stable we will emit that warning in all files
outside of `app/`.
This ensures we leverage the fetch cache when calling
`generateStaticParams` and also ensures paths with
`generateStaticParams` without `dynamicParams = false` don't error when
only partial params are provided.
x-ref: [slack
thread](https://vercel.slack.com/archives/C035J346QQL/p1678149362238089)
Add unique identifier `@app@` / `@pages@` / `@root@` for entry key of on
demand entries, so that they'll be unique for each path when the page
key is similar bewteen app and pages like (`"app/page"` and
`"pages/page"` will both end up with `/page`)
## Bug
Follow up for #46736
Closes NEXT-472
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
---------
This PR adds the support for unnamed default export expression support
`export default async function () {}` in a "use server" entry, with
corresponding test.
Also fixed an existing bug that the default exported action's name
should be aligned with the export name, which is `"default"`.
Closes NEXT-769.
This updates to no longer skip caching POST or authed requests with the
fetch cache and instead we bail when `cookies()` or `headers()` is used
prior which is a better heuristic to signal user specific data would be
related to the fetch request.
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1678130069138849)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
Currently all helper functions are exported from huge utils files. This
moves the helper functions to their own files, this approach aligns
better with the rest of the codebase.
The unit tests are split up and colocated with the function it tests.
Also added some missing tests.
Plus some overall cleanup, added comments and fixed types.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
This PR makes `typedRoutes` stricter by constraining generics in `Route` to type string. I've also made generating types for routes a bit more efficient by moving `redirects` and `rewrites`'s processing to the plugin's constructor since `rewrites` and `redirects` don't change in both dev and prod.
I've also been trying to fix a bug where route types doesn't generate all the routes (some appear, some don't), but I've got no clues since that doesn't seem easy to reproduce (perhaps it only happens in my case?)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.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`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Turbopack uses a different format for its css module classnames [0].
This adds and uses a helper function to the next-font tests to assert
against these classnames when testing with Turbopack. Ideally these
tests could be more behavioral (e.g. asserting on rendered dimensions),
but these can't capture things like fallback fonts.
[0] https://github.com/vercel/turbo/pull/3437
Since we have 2 server compilers (node and edge), the `serverActions`
object will always get overridden by the second compilation during `next
build`. Like the client reference manifest, we need to have 2 objects
for each compiler and merge them when outputting the asset.
Besides that, to avoid `export default` being tree-shaken as unused
export, I changed the loader to use CJS `module.exports` instead. Can't
easily figure out a proper way for now but we plan to create separate
worker for the action endpoint and this will be gone then.
Fixes NEXT-759, read NEXT-761 for the full future plan.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Use some utils to match multiple dom nodes together
#### Match multiple props for single DOM node
```tsx
const matchDom = createDomMatcher(browser)
await matchDom('meta', 'name="description"', { content: 'description' })
```
#### Match multiple same pattern DOM nodes in html
```tsx
const $ = await next.render$('html')
const matchHtml = createHtmlMatcher($)
await matchHtml('meta', 'name', 'property', {
description: 'description',
og: 'og:description'
})
```
#### Match same pattern DOM nodes in browser after hydration
```tsx
const matchMultiDom = createMultiDomMatcher(browser)
await matchMultiDom('meta', 'property', 'content', {
description: 'description',
'og:title': 'title',
'twitter:title': 'title'
})
```
## Background
In the early days, `next export` was created when Next.js was SSR-only in order to statically export your pages for self hosting where no server was available. However, around the time `getStaticProps()` and `getStaticPaths()` were introduced, Next.js began [automatically generating static pages](https://nextjs.org/docs/advanced-features/automatic-static-optimization) (SSG first and SSR opt-in) during `next build`. This meant there were very few reasons to use `next export` and it started to become a stale feature.
## Problem We Need To Solve
Users targeting `next export` currently have a really bad experience. They start a new project and use all the features Next.js has to offer because they all features work with `next dev`. Then when development is finished and it comes time to deploy, running `next build && next export` will fail with errors for [unsupported features](https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features).
## Solution
This PR introduces a new configuration option, `output: 'export'`, to indicate that the user intends to run `next export`.
With this change, Next.js can fail fast during `next dev` if any [unsupported features](https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features) are used, thereby improving developer experience with instant feedback.
```js
/**
* @type {import('next').NextConfig}
*/
const nextConfig = {
output: 'export',
}
module.exports = nextConfig
```
