Part of #47759 (which had been reverted twice so here we only land a part of the change), relates to NEXT-926. Thanks to #48506 we can soon switch between these two channels during runtime.
Also fixes a problem of `renderKind` (only revealed after upgrading React), it should be also based on the `match` kind.
### What?
Update `@swc/helpers` to `v0.5.1`.
### Why?
Webpack merges `@swc/helpers@v0.4.x` and `@swc/helpers@v0.5.x`, due to `resolve.alias` config in 2f6ff0dab3/packages/next/src/build/webpack-config.ts (L1070-L1072)
To workaround it, `@swc/helpers@v0.5.1` reexports from entries just like `v0.4`.
### How?
Closes WEB-948
Fixes#48593
We decided in https://github.com/vercel/next.js/pull/48308 that we won't
use `turbo` when packing packages for tests.
This PR removes all code associated with that effort. The whole thing
fas behind a flag, so it shouldn't affect anything.
fix NEXT-1025
Reverts vercel/next.js#48038
fix NEXT-926
---
The root cause was that when copying the package.json, I removed all
fields except for a few (such as `exports`) but missed the `browser`
field. That caused the client bundle to resolve to the Node.js version
of React DOM, and then we had the `async_hooks` error. Added it back in
99c9b9e51f8b0d4e4503ece9d07bce09161f3341.
I reproduced the error with next-site earlier and confirmed that this
fix is good.
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
As discussed this adds a publish workflow that can be triggered for
canary or stable releases which ensures we are publishing from a
consistent environment and local config doesn't affect a release.
This ensures the build spinner is correctly stopped in a TTY environment
and also adds regression tests for `app` and `pages` to ensure this
behaves as expected.
This updates our docker image to use the `jammy` tag instead of `focal`
to match the Ubuntu version to our CI.
Reverts vercel/next.js#47372
```
Error occurred prerendering page "/apple-icon". Read more: https://nextjs.org/docs/messages/prerender-error
Error: The `ImageResponse` API is not supported in this runtime, use the `unstable_createNodejsStream` API instead or switch to the Vercel Edge Runtime.
at new ImageResponse (/tmp/next-install-db63e2a2f25e9feda48affa69456fcbdde8d89bf94645e42abd2aa522224f432/.next/server/chunks/558.js:26416:19)
at appleIcon (/tmp/next-install-db63e2a2f25e9feda48affa69456fcbdde8d89bf94645e42abd2aa522224f432/.next/server/app/apple-icon/route.js:127:12)
```
https://github.com/vercel/next.js/actions/runs/4490842502/jobs/7899302486#step:6:305
Allow image responses returning from dynamic image routes for og/twitter
images, and icon/apple-icon images. This PR supports the basic
functionalities for nodejs runtime of image routes. `@vercel/og` is able
to be leveraged for generating dynamic image responses.
Close NEXT-264
Close NEXT-266
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This reverts #31408, as it also sets the git config value
`index.skipHash` which breaks cargo at the moment:
https://github.com/rust-lang/cargo/issues/11857
Contributors docs have been updated to recommend a shallow clone in
#44158, which should alleviate some of the issues that manyFiles
addresses.
### 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
Since we intend to update our vendored copy of React frequently, I wrote
a script to automate the steps.
Basic usage (defaults to most recent React canary version):
```sh
pnpm run sync-react
```
Specify a canary version:
```sh
pnpm run sync-react --version 18.3.0-next-41110021f-20230301
```
Update package.json but skip installing the dependencies automatically:
```sh
pnpm run sync-react --no-install
```
At the end it will print out a changelog so you can copy/paste it into
the PR description.
<!--
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)
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>
Adds additional integration tests for `@next/mdx`.
- Test mdx-rs
- Test `mdx-components.tsx`
- Tests development and production. Previously it only checked
development.
<!--
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)
---------
Co-authored-by: Shu Ding <g@shud.in>
<!--
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 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
- [x] 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)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
When incompatibilities with upgrades to `swc` occur between releases,
these changes expand the existing `pnpm clean` script to additionally
run any `clean` script under any of the lerna packages. In this case, a
new script was created under `packages/next-swc` that removes
`packages/next-swc/native/*`, allowing the default to automatically use
the WASM build.
Users wanting to reset their repository can now run:
```sh
pnpm clean
```
Future packages or outputs that are built should have their `clean`
script remove them to allow for easy repository resetting.
This reverts commit fd9ec646ac.
It seems that there is an issue with caching of inputs which uses stale
files.
We also had to disable caching of `pnpm-lock.yaml` because it requires
stable package locations chich we removed.
Updates our test config to take advantage of more concurrency and also
updates to leverage the playwright docker image to reduce flakes from
actions/setup-node stalling or playwright dependencies stalling on `apt
install`.
This reduces our test times from upwards of 30 minutes down to back
around 15 minutes.
Continuation of https://github.com/vercel/next.js/pull/42711 fixing
latest turbo usage in musl environment
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a helpful link attached, see `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 adds a basic test case to ensure Next.js and Edge Runtime
changes don't break the image generation feature, as well as record the
usage.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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`
- [x] Integration tests added
- [ ] Documentation added
- [x] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `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)
Ensures we have latest patches in turbo CLI.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a helpful link attached, see `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)
Updates builtin react to latest release on next channel
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a helpful link attached, see `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)
<!--
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 that you're making:
-->
This PR implements a configuration option in `next.config.js` to support
for rust-based MDX compiler (https://github.com/wooorm/mdxjs-rs).
Currently it is marked as experimental, as mdx-rs and loader both may
need some iteration to fix regressions.
When a new experimental flag is set (`mdxRs: true`), instead of using
`@mdx/js` loader `next/mdx` loads a new webpack loader instead.
Internally, it mostly mimics mdx/js's loader behavior, however actual
compilation will be delegated into next/swc's binding to call mdx-rs's
compiler instead.
I choose to use next-swc to expose its binding function, as mdx-rs
internally uses swc already and creating new binary can double up
bytesize (with all the complex processes of publishing new package).
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
We insert the content returning from `useServerInsertedHTML` to head
element for app dir, but it shouldn't only inject once since there're
suspense boundaries that could hold insertions.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
Co-authored-by: JJ Kasper <jj@jjsweb.site>
We found a case where 14.0.0 breaking with private class methods, such
as:
```js
class C {
#x() { return 42; }
x() {
return this.#x();
}
}
```
This feature was introduced in Node.js 14.6.0, so we can bump the
minimum version.
See https://node.green
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>
This PR updates `@types/node` to `14.14.31`. The most important type is
that `ParsedUrlQuery` can hold `undefined` so we are updating the code
here to explicitly handle those cases. Aside from it we are adding a
global definition taken from NodeJS for `AsyncLocalStorage` that we
export in `server.d.ts`
Next.js 13 will require React 18.
In this PR I've only updated the peerDependency and removed the test runs in GH actions. Further cleanup will follow later, this allows us to remove the code supporting it later.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
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>
Currently `react-dom` isn't handled as an external dependency in SSR,
unlike `react`. This means that the ReactDOM imported by client
components isn't the same instance as the ReactDOM that does SSR.
This PR also upgrades React experimental to the latest version.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
As discussed this updates our required minimum Node.js version to `v14` as `v12` is no longer being maintained. Since our targets for babel and swc already target the actively used Node.js version no change has been made there.
Re-lands #40335 but without modifying the lock file.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
Utilize `turbo` for `dev`, and make sure polyfills are built. Fixes#40334
Another option would be to document that an initial `pnpm build` is necessary in [`CONTRIBUTING.md`](https://github.com/vercel/next.js/blob/canary/contributing.md#developing).
## 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)
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
@ijjk moving this here.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
For some context:
https://vercel.slack.com/archives/CGU8HUTUH/p1662124179102509
Adds `@next/font` package.
`scripts/update-google-fonts.js` generates functions and metadata for
all available google fonts. The metadata is used in `loader.ts` to
validate font options (from #40221). It then fetches the CSS from google
fonts, downloads the font files and emits them as static assets.
The actual integration with `packages/next` and integration tests
depends on #40221, will follow up with new PR.
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>
Fixes build errors related to
https://github.com/browserslist/caniuse-lite/issues/102
see
https://github.com/vercel/next.js/actions/runs/3082979772/jobs/4983345078
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
Only upgrade react-exp.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a 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 a 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/examples/adding-examples.md)
Continues #39778Closes#40499
## 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: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
- Use React.startTransition instead of useTransition
- Upgrade to latest React experimental
- Split router cache invalidate into separate function
Some minor cleanup while verifying behaviors.
<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order 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 that you're making:
-->
This serves to add support for [Subresource
Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity)
hashes for scripts added from the new app directory. This also has
support for utilizing nonce values passed from request headers (expected
to be generated per request in middleware) in the bootstrapping scripts
via the `Content-Security-Policy` header as such:
```
Content-Security-Policy: script-src 'nonce-2726c7f26c'
```
Which results in the inline scripts having a new `nonce` attribute hash
added. These features combined support for setting an aggressive Content
Security Policy on scripts loaded.
## 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.
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] 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: Steven <steven@ceriously.com>
Typescript published 4.8.2 today and it fails CI, bump our typescript version to 4.8.2 and tweak some typings to make existing e2e typescript tests work properly
* Bump web-vitals from 3.0.0-beta to 3.0.0 stable for typing fix (there's an undefined type but it wasn't caught by ts 4.7), also force compiled it as CJS for pre-compiled
* Bump ncc to 3.34.0 for ts-loader compatibility for new typescript version, ncc 3.33.x cannot work with ts 4.8
* Update pre-compiled
### Problem
esm modules imports from client components will be compiled to `m = import('module-name')` when webpack bundles them for server components flight rendering. In this case, they will all become async modules since dyanmic imports will return a promise which react flight cannot handle it then results into module resolving error on server flight rendering.
### Solution
* React flight renderer supports handling async modules in https://github.com/facebook/react/pull/25138
* On next.js side leverage the module proxy change for each client reference, to make sure it always resolve the correct client module
The idea is wrapping each module with a module proxy, and if the module is async and accessed as thenable, it will return a new module reference with `async` label to tell react to handle it as async modules:
exported client reference `*` --> not async module (non thenable) --> original module reference `''`
exported client reference `*` --> it's async module (thenable) --> wrapped module reference `'*'` with `async` label
### Note
Since we need to check if user having incorrect gSSP/gSP specifying in layout client componet, so we still need to parse it and assign those info to the proxy (Does client module containing `ssr`, `ssg` exports). Otherwise the proxy will return the cached module reference
Upgrade experimental React, and render link tags directly in the tree during development. The client bundle won't import CSS anymore, and server CSS imports will be transpiled into no-op strings just for HMR to use.
## Follow Ups
- [ ] Flash of unstyled elements when reloading styles
- [ ] Collect client style imports
- [ ] Console warning for duplicated resources
- [ ] Tests
## 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)
* 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>
Use flush effects to custom apply css-in-js solution to app. Re-introduce flush effects to app-render, and remove default support of styled-jsx in `app/`. So that users will choose their own css-in-js solution if they need any customization. styled-jsx won't appear in client bundle if you didn't use it.
For now we have to inject the initial styles before `</head>` to avoid hydration errors. Later on we can remove this once react can handle it.
- [x] inject styles before end of head element
- [x] add tests
This commit allows the users to import URLPattern from `next/server`,
by defining a key that uses `global.URLPattern`.
Why is this any good? or: why don't we add URLPattern to the global namespace?
URLPattern is exposed as global on Edge Runtime _only_. This means that if we define a
constructor in global namespace in our TypeScript definitions, people might
have runtime errors in their Node.js functions.
Importing from `next/server` enables users to get the constructor without
risking in runtime errors and wrong type definitions.
Keep in mind, that with the current implementation, we do not check if the
constructor actually exists, but `next/server` shouldn't be imported in
Node.js functions, AFAIK.
## Related
- Fixes#38131
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This PR updates the Edge Runtime to use a new version that loads dependencies differently. This addresses https://github.com/vercel/next.js/pull/38766 so `instanceof` works as expected.
It involved a few code changes, mostly regarding to types. The most important change is that the `Runner` function in the sandbox doesn't take a `ReadableStream` as `body` anymore since this implies creating the instance on "node land" and makes the runtime `fetch` function not to be able to compare with `ReadableStream` using `instanceof`. Instead we introduce a "clonable body" abstraction that allows to create the `ReadableStream` from `Readable` by using the edge runtime primitive which would hold the correct prototype.
Also, this PR changes the way we pre-compile the Edge Runtime to adapt it to the new version.
Updates to latest turbo which includes patches for cached files.
x-ref: [slack thread](https://vercel.slack.com/archives/C02CDC2ALJH/p1657767763630359?thread_ts=1657757803.039099&cid=C02CDC2ALJH)
## 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)
Ensures you can use server context when navigating.
## 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 PR introduces an environment variable that allows to modify the `EdgeRuntime` value on compilation time.
This is done to allow cloud providers like Vercel to have a different value, and enable user code and 3rd party libraries to have different code paths depending on the Edge Functions provider.
## Related
- Related to #30739
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Previously we use custom webpack alias for specific react versions for non server side node runtime aliases. This PR alias the entire folders of `react/` and `react-dom/` so that no more alias in next.config is required but only the nodejs require hook.
* Alias `react` and `react-dom` by default
* Use `react@experimental` to run server components integration test
* Drop with-react-17 test util, add `__NEXT_REACT_CHANNEL` as an env var for testing and development to specify the react channel is 17 or new experimental version
* Adds tests to ensure `eslint-plugin-next`'s available rules are properly exported and recommended rules are defined correctly.
* Condenses imports.
* Sets default recommended value.
* replace Object.hasOwn for node 14
Co-authored-by: JJ Kasper <jj@jjsweb.site>
In a previous PR (#37278), the dependencies for benchmarks were moved to a subdirectory.
This ensures the same is done for other packages using `rimraf` which means we can remove it from the root package.json
This allows configuring / overriding the default options of the `styled-components` swc transform and allows using the `css` prop support, which was already implemented, but not available.
Edit: made the CSS prop transform run before the display name, so it gets picked up by that and receives the (deterministic) name.
Relates to #30802
### What's in there?
This is a followup of https://github.com/vercel/next.js/pull/37695.
For the dev server to clean stacktraces, we're decorating errors caught during code evaluation (`getServerSideProps` or middleware).
However, when these errors are asynchronously raised, we can't decorate them before processing them, leading to this fallback logic:
bf7bf8217f/packages/next/server/dev/next-dev-server.ts (L775-L779)
Thanks to latest improvement of the edge-runtime in 1.1.0-beta.4, we can now catch unhandled rejection and uncaught exception, and decorate them.
### How to test?
Please reuse the existing tests who already covered these cases:
`pnpm testheadless --testPathPattern middleware-dev-errors`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
