Next.js includes various feature sets that depend on specific release
channels of React. However, our current setup only includes the `next`
channel of React, which restricts our ability to integrate with features
available on the `experimental` channel.
To address this limitation, this pull request introduces the following
changes:
- Vendors the `react@experimental` version, along with the corresponding
`react-dom` and `scheduler` packages.
- Modifies the `sync-react` script to also update the `experimental`
channel and removes `--version` as they're always synced to the latest
now.
- Retains the default behavior of using the `next` channel in the
`appDir` directory.
- Adds an option to switch to the `experimental` channel by setting
`experimental.experimentalReact: true` in the configuration.
fix NEXT-926 ([link](https://linear.app/vercel/issue/NEXT-926))
### What?
This PR vendors @vercel/og and export `ImageResponse` from
`next/server`. When you render a opengraph image the below code snippets
will be legit:
```tsx
import { ImageResponse } from 'next/server'
export default function og() {
return new ImageResponse(<div style={{ width: '100%', height: '100%' }}>hello</div>)
}
```
### Why?
To make development more easier, user can directly use `@vercel/og`
Image Response with nextjs instead of install it and use it. This makes
building metadata icons, og or twitter images more convenient.
### How?
Closes NEXT-899
### What?
- Besides existing `Metadata` type, expose `ResolvingMetadata` and `ResolvedMetadata` to `'next'`.
- Group `Robots` / `Sitemap` / `Manifest` these dynamic data routes types as `MetadataRoute` type and expose to `'next'`
### Why?
Allow users to type the more API easily, and grouping them to avoid type conflicts (e.g. we have `Robots` in metadata interface field, `MetadataRoute.Robots` can avoid conflicts)
### How?
Closes NEXT-908
* Add `manifest.webmanifest` and `manifest.(j|t)xs?` support for
manifest.json route
* Add `Manifest` type for it for autocomplete purpose.
Remove the exports for `SitemapFile` and `RobotsFile` globally, will
discuss how to re-export them with better naming later
Small fix for `Robots` typing, should allow `string | string[]` for user
agent of single Robots
Closes NEXT-839
---------
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 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.
Leverage edge build of react-server-dom-webpack on server and keep
browser build of it for client build
Closes NEXT-606
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
fixes NEXT-479
## content
This PR adds a `getTracer` API to Next.js that uses the `otel/api` under
the hood to provide Next.js level instrumentation through Open
Telemetry.
This also adds an example `with-opentelemetry` to demonstrate how it can
be used, assuming you have a collector.
This allows most notably to have `getServerSideProps` and `fetch` calls
inside Server Components traced.
## details
- we hide most internals spans, if you want to see all of them, use the
NEXT_OTEL_VERBOSE=1 env var
- if you want to use this, you'll need to rely on the
`config.experimental.instrumentationHook` config option to initialise
OTEL, like in the example
## 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)
Enables using `next/font` by adding `@next/font` as a dependency and
reexporting its loaders.
Always generates the `font-loader-manifest` as we can't know beforehand
if the user intends to use `next/font` or not.
Also adds telemetry for `next/font` usage.
The tests are updated to use `next/font`. But `@next/font` is tested in
`test/e2e/next-font/index.test.ts` and `test/e2e/app-dir/next-font` as
well to ensure it doesn't break.
Fixes NEXT-351
## 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 adds a top-level experimental config for including/excluding files
from the file traces. This replaces the page level
`unstable_includeFiles`/`unstable_excludeFiles` as those had some
drawbacks such as not being supported for API routes as these files
aren't required during build to gather the configs, having to duplicate
includes/excludes for multiple pages, and causing more confusion for
where the globs were meant to be relative to.
The new top-level configs allow mapping page globs to includes/excludes
so they can be shared across multiple pages or a single page. These can
also affect the `next-server` trace by specifying that as the key if
necessary. The previous `outputFileTraceIgnores` config is automatically
mapped to the new config with a deprecation warning.
## 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
- [x] 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)
Bundle the ssr client layer for RSC, this solves the problem when
there's an esm package is using on client components, but esm imports
the installed react instead of the built-in react version since esm
imports is not intercepted by require hook.
After bundling the ssr client layer and treating react as externals, now
react compiles as cjs externals and could be intercepted by require
hook, other code are bundled together which can also get optimized.
## 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`
- [x] Integration 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`
Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Inline a react and react-dom for app dir, when `appDir` flag is enabled
opt into the built-in version for all.
For server layer react, use the react share subset for server
components.
For all server side of react-dom usage, use the server-rendering-stub.
Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This commit implements the main proposal presented in
https://github.com/vercel/next.js/issues/39241
to add attribution to web vitals.
Attribution adds more specific debugging info to web vitals,
for example in the case of Cumulative Layout Shift (CLS),
we might want to know
> What's the first element that shifted when the single largest layout shift occurred?
on in the case of Largest Contentful Paint (LCP),
> What's the element corresponding to the LCP for the page?
> If it is an image, what's the URL of the image resource?
Attribution is *disabled* by default because it could potentially
generate a lot data and overwhelm the RUM backend.
It is enabled *per metric* (LCP, FCP, CLS, etc)
As part of this change, `web-vitals` has been upgraded to v3.0.0
This version contains minor bug fixes, please see changelog at
9fe3cc02c8Fixes#39241
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] 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`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [x] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This PR adds a new `experimental.enableUndici` option to let the
developer switch from `next-fetch` to `undici` as the underlying
polyfill for `fetch` in Node.js.
In the current implementation, Next.js makes sure that `fetch` is always
available by using `node-fetch`. However, we do not polyfill in Node.js
18+, since those versions come with their own `fetch` implementation
already, built-in.
Node.js 18+ uses `undici` under the hood, so letting the developer use
`undici` earlier could make the migration easier later on.
Eventually, we hope to be able to stop polyfilling `fetch` in an
upcoming major version of Next.js, shipping less code.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Sukka <isukkaw@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Steven <steven@ceriously.com>
Currently, a developer building a website using Next.js could write this
code with no type errors:
```tsx
<Image
width="kangaroo"
height="100px"
quality="medium"
{...rest}
/>
```
This PR adds stricter type checking, which will catch this type of error
earlier.
Similarly, this PR adds stricter types for the `responseLimit`, to
ensure the types align to:
https://nextjs.org/docs/messages/api-routes-response-size-limit
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Problem
Currently the Next.js infer utility (`InferGetServerSidePropsType` and
`InferGetStaticPropsType`) types can lead to a wrong inferred types
(`never`). This happens if these functions return something different
than: `{props: {}}`.
**Example:** `getServerSideProps`
```typescript
export async function getServerSideProps({ query }: GetServerSidePropsContext) {
if (query.foo) {
return {
notFound: true,
}
}
return {
props: {
foo: "bar"
},
}
}
type PageProps = InferGetServerSidePropsType<typeof getServerSideProps>
// => type PageProps = never
```
**Example:** `getStaticProps`
```typescript
import type { InferGetStaticPropsType, GetStaticPropsContext } from 'next'
export async function getStaticProps(context: GetStaticPropsContext) {
if (context.params?.bar) {
return {
notFound: true,
}
}
return {
props: {
foo: 'bar',
},
}
}
type PageProps = InferGetStaticPropsType<typeof getStaticProps>
// => type PageProps = never
```
This is because the first infer condition of the utility type is not
satified leading to a never result.
```typescript
export type InferGetServerSidePropsType<T> = T extends GetServerSideProps<
infer P, // <- NOT SATISFIED
any
>
? P
: T extends (
context?: GetServerSidePropsContext<any>
) => Promise<GetServerSidePropsResult<infer P>>
? P
: never // <- NOT SATISFIED
```
## Solution
I have experimented with different solutions ending with a much simpler
type, that is faster to execute, easier to read and universally usable
for both prop variations.
```typescript
/**
* Flow:
* - Make sure getStaticProps is a function
* - Get its return type
* - Extract the one that contains {props: any}
* - Return the props
*/
export type InferGetStaticPropsType<T extends (args: any) => any> = Extract<
Awaited<ReturnType<T>>,
{ props: any }
>['props']
```
## Bug
- [x] Related issues: fixes#36615, #15913,
https://twitter.com/leeerob/status/1563540593003106306
- [x] Type tests added
## Future thoughts
Since `InferGetStaticPropsType` and `InferGetServerSidePropsType` are
now the same, it's api could be merged into one utility type (e.g:
InferNextProps). I recommend doing this in a different PR.
## Additional info
I have tested this approach using the following [external
package](https://www.npmjs.com/package/infer-next-props-type)
(@timneutkens sorry for the late PR). Since about 12 Month I haven't
received any negative feedback (issues) regarding this approach.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Enables some rules that are useful and already pass currently.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Follow-up to the earlier enabling of classes/variables etc.
Bug
Related issues linked using fixes #number
Integration tests added
Errors have helpful link attached, see 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
Integration tests added
Documentation added
Telemetry added. In case of a feature if it's used or not.
Errors have helpful link attached, see contributing.md
Documentation / Examples
Make sure the linting passes by running pnpm lint
The examples guidelines are followed from our contributing doc
Co-authored-by: Steven <steven@ceriously.com>
follow-up for #39518
* revert `styled-jsx/style` import path to `next/dist/shared/styled-jsx`
* Since `styled-jsx` cannot be resolved through `node_modules/next/node_modules` by external resolving, we forcedly resolve styled-jsx as cjs external in webpack
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Improve styled-jsx types in next.js, previously there's no `declare module` for styled-jsx and there's type name conflicts in `styled-jsx/index.d.ts` and we use a rename hack to avoid the conflicts. Now styled-jsx 5.0.3 fixed those issues.
x-ref: https://github.com/vercel/styled-jsx/pull/805
* Use require hook and alias to resolve styled-jsx
* re-export styled-jsx types from compiled
* fix lint
* add test for styled-jsx css
* setup require hook in server
* compile import path to styled-jsx/style
* revert require hook
* add test for server styled-jsx resolving
* update test
* pre copy styled-jsx assets
* fix styled-jsx dts
* add npmrc for styled-jsx e2e test
* load require hook directly
* rm legacy test
* fix lint
* fix pnpm install error
* split require hook
* only alias styled-jsx
* make styled-jsx resolving statically analyzable
* update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Add runtime to PageConfig type
* Add test case for runtime type
* Apply suggestions from code review
* dedupe type
* fix import
* fix lint
Co-authored-by: JJ Kasper <jj@jjsweb.site>
We were resizing animated images when importing them, but we don't optimize images when they come from an upstream provider. For consistency, we can skip resizing for local animated images as well.
Fixes#39317
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `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`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This ensures we expose the `styled-jsx` types correctly even when the package is not hoisted from next's `node_modules` e.g. when using `pnpm`. We had an existing test that covered this although it installed `styled-jsx` at the top-level as a workaround so the test has been updated to remove this workaround.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/pull/37828#discussion_r901164193
This PR introduces [Edge Runtime](https://edge-runtime.vercel.app/) for emulating [Edge Functions](https://vercel.com/features/edge-functions) locally.
Every time you run a [middleware](https://nextjs.org/docs/advanced-features/middleware) locally via `next dev`, an isolated edge runtime context will be created.
These contexts have the same constraints as production servers, plus they don't pollute the global scope; Instead, all the code run in a vm on top of a Node.js process.
Additionally, `@edge-runtime/jest-environment` has been added to make easier testing Edge Functions in a programmatic way.
It dropped the following polyfills from Next.js codebase, since they are now part of Edge Runtime:
- abort-controller
- formdata
- uuid
- web-crypto
- web-streams
Co-authored-by: Gal Schlezinger <2054772+Schniz@users.noreply.github.com>
