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>
Follow-up to https://github.com/vercel/next.js/pull/36527 this adds falling back to the wasm swc build when loading the native bindings fails so that we don't block the build on the native dependency being available.
This continues off of https://github.com/vercel/next.js/pull/33496 but does not add a postinstall script yet and only downloads the fallback when the native dependency fails to load.
List all exports for internal path module to avoid import destruction is breaking with typescript.
#### Prev
```js
import pathMod from '../isomorphic/path'
const { join, resolve } = pathMod
```
#### Now
```js
import { join, resolve } from '../isomorphic/path'
```
x-ref: #36190
x-ref: #31506
* Move nodejs ptah module usage to next-server, keep base-server and web-server headless for `'path'`
* Use a native module `path` for nodejs runtime and `path` polyfill for edge runtime
Adds an API config option that disables warning a user when their API response body is over 4 megs. This has been added for users who'd like to stream larger amounts of data from their API acknowledging the drawbacks. This config mirrors the existing [`externalResolver` config](https://nextjs.org/docs/api-routes/api-middlewares#custom-config).
Closes: [#33162](https://github.com/vercel/next.js/issues/33162)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Fixes the problem that global `process` variable has only the `env` field.
Also fixed the issue that the `env` field is empty when the `process` module is used as the value of the variable (which happens when the module is contained in a dependency of application).
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
* Update server-only changes HMR handling
* Add failing tests for GS(S)P server only changes
* update test
* normalize backslashes
* Update to xor the chunk hashes
* remove test change
* remove other test change
This value has been deprecated in favor of `typeof window !== 'undefined'` a long time ago ([ref](https://github.com/vercel/next.js/pull/7651)). We should also deprecate the value in the global types as it might give the wrong assumption that this value should still be used.
It adds AbortController and AbortSignal Web runtimes APIs to be used by the user at Edge Functions.
For doing that it delegates into `abort-controller` dependency that has been frozen to prevent any modification.
Co-authored-by: Zhang Zhi <20026577+fytriht@users.noreply.github.com>
