Merge branch 'canary' into issue/vercel#30962

.github/workflows/build_test_deploy.yml

@@ -816,13 +816,9 @@ jobs:
     runs-on: ubuntu-latest
     needs: [build, build-native-test]
     env:
-      BROWSERSTACK: true
       BROWSER_NAME: 'safari'
-      NEXT_TELEMETRY_DISABLED: 1
       NEXT_TEST_MODE: 'start'
-      SKIP_LOCAL_SELENIUM_SERVER: true
-      BROWSERSTACK_USERNAME: ${{ secrets.BROWSERSTACK_USERNAME }}
-      BROWSERSTACK_ACCESS_KEY: ${{ secrets.BROWSERSTACK_ACCESS_KEY }}
+      NEXT_TELEMETRY_DISABLED: 1
     steps:
       - name: Setup node
         uses: actions/setup-node@v3
@@ -851,18 +847,19 @@ jobs:
       - run: npm i -g pnpm@${PNPM_VERSION}
         if: ${{needs.build.outputs.docsChange == 'nope'}}
 
-      # TODO: use macos runner so that we can use playwright to test against
-      # PRs instead of only running on canary?
-      - run: '[[ -z "$BROWSERSTACK_ACCESS_KEY" ]] && echo "Skipping for PR" || npm i -g browserstack-local@1.4.0'
+      - run: npx playwright install-deps && npx playwright install webkit
         if: ${{needs.build.outputs.docsChange == 'nope'}}
 
-      - run: '[[ -z "$BROWSERSTACK_ACCESS_KEY" ]] && echo "Skipping for PR" || node run-tests.js -c 1 test/integration/production/test/index.test.js test/e2e/basepath.test.ts'
+      - run: node run-tests.js -c 1 test/integration/production/test/index.test.js test/e2e/basepath.test.ts
+        if: ${{needs.build.outputs.docsChange == 'nope'}}
+
+      - run: DEVICE_NAME='iPhone XR' node run-tests.js -c 1 test/production/prerender-prefetch/index.test.ts
         if: ${{needs.build.outputs.docsChange == 'nope'}}
 
   testSafariOld:
     name: Test Safari 10.1 (nav)
     runs-on: ubuntu-latest
-    needs: [build, testSafari, build-native-test]
+    needs: [build, build-native-test]
     env:
       BROWSERSTACK: true
       LEGACY_SAFARI: true
@@ -1441,7 +1438,7 @@ jobs:
     if: ${{ needs.build.outputs.isRelease == 'true' }}
     needs: build
     name: stable - x86_64-unknown-freebsd - node@16
-    runs-on: macos-10.15
+    runs-on: macos-12
     steps:
       - name: tune mac network
         run: sudo sysctl -w net.link.generic.system.hwcksum_tx=0 && sudo sysctl -w net.link.generic.system.hwcksum_rx=0
@@ -1456,7 +1453,7 @@ jobs:
           rm -rf test
       - name: Build
         id: build
-        uses: vmactions/freebsd-vm@v0.1.6
+        uses: vmactions/freebsd-vm@v0.2.0
         env:
           DEBUG: napi:*
           RUSTUP_HOME: /usr/local/rustup

contributing.md

@@ -306,9 +306,13 @@ Execute [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packag
 
 ```bash
 npx create-next-app --example DIRECTORY_NAME DIRECTORY_NAME-app
-# or
+```
+
+```bash
 yarn create next-app --example DIRECTORY_NAME DIRECTORY_NAME-app
-# or
+```
+
+```bash
 pnpm create next-app --example DIRECTORY_NAME DIRECTORY_NAME-app
 ```
 

docs/advanced-features/react-18/overview.md

@@ -1,7 +1,6 @@
 # React 18
 
 [React 18](https://reactjs.org/blog/2022/03/29/react-v18.html) adds new features including Suspense, automatic batching of updates, APIs like `startTransition`, and a new streaming API for server rendering with support for `React.lazy`.
-Next.js also provides streaming related APIs, please checkout [next/streaming](/docs/api-reference/next/streaming.md) for details.
 
 React 18 is now released. Read more about [React 18](https://reactjs.org/blog/2022/03/29/react-v18.html).
 

docs/advanced-features/react-18/streaming.md

@@ -2,8 +2,6 @@
 
 React 18 includes architectural improvements to React server-side rendering (SSR) performance. This means you can use `Suspense` in your React components in streaming SSR mode and React will render content on the server and send updates through HTTP streams.
 
-React Server Components, an experimental feature, is based on streaming. You can read more about Server Components related streaming APIs in [`next/streaming`](/docs/api-reference/next/streaming.md). However, this guide focuses on streaming with React 18.
-
 ## Using Streaming Server-Rendering
 
 When you use Suspense in a server-rendered page, there is no extra configuration required to use streaming SSR. When deployed, streaming can be utilized through infrastructure like [Edge Functions](https://vercel.com/edge) on Vercel (with the Edge Runtime) or with a Node.js server (with the Node.js runtime). AWS Lambda Functions do not currently support streaming responses.
@@ -12,7 +10,7 @@ All SSR pages have the ability to render components into streams and the client
 
 As an added bonus, in streaming SSR mode the client will also use selective hydration to prioritize component hydration based on user interactions, further improving performance.
 
-For non-SSR pages, all Suspense boundaries will still be [statically optimized](/docs/advanced-features/automatic-static-optimization.md). Check out [`next/streaming`](/docs/api-reference/next/streaming.md) for the API reference for streaming SSR.
+For non-SSR pages, all Suspense boundaries will still be [statically optimized](/docs/advanced-features/automatic-static-optimization.md).
 
 ## Streaming Features
 

docs/api-reference/next/future/image.md

@@ -39,6 +39,13 @@ Compared to `next/image`, the new `next/future/image` component has the followin
 - Note: there is no `fill` mode so `width` & `height` props are required
 - Note: the [`onError`](#onerror) prop might behave differently
 
+The default layout for `next/image` was `intrinsic`, which would shrink the `width` if the image was larger than it's container. Since no styles are automatically applied to `next/future/image`, you'll need to add the following CSS to achieve the same behavior:
+
+```css
+max-width: 100%;
+height: auto;
+```
+
 ## Required Props
 
 The `<Image />` component requires the following properties.

docs/basic-features/data-fetching/get-static-paths.md

@@ -9,17 +9,28 @@ If a page has [Dynamic Routes](/docs/routing/dynamic-routes.md) and uses `getSta
 When you export a function called `getStaticPaths` (Static Site Generation) from a page that uses dynamic routes, Next.js will statically pre-render all the paths specified by `getStaticPaths`.
 
 ```jsx
+// pages/posts/[id].js
+
+// Generates `/posts/1` and `/posts/2`
 export async function getStaticPaths() {
   return {
-    paths: [
-      { params: { ... } }
-    ],
-    fallback: true // false or 'blocking'
-  };
+    paths: [{ params: { id: '1' } }, { params: { id: '2' } }],
+    fallback: false, // can also be true or 'blocking'
+  }
 }
-```
 
-`getStaticPaths` **must** be used with `getStaticProps`. You **cannot** use it with [`getServerSideProps`](/docs/basic-features/data-fetching/get-server-side-props.md).
+// `getStaticPaths` requires using `getStaticProps`
+export async function getStaticProps(context) {
+  return {
+    // Passed to the page component as props
+    props: { post: {} },
+  }
+}
+
+export default function Post({ post }) {
+  // Render post...
+}
+```
 
 The [`getStaticPaths` API reference](/docs/api-reference/data-fetching/get-static-paths.md) covers all parameters and props that can be used with `getStaticPaths`.
 
@@ -45,14 +56,52 @@ You should use `getStaticPaths` if you’re statically pre-rendering pages that
 
 ## Where can I use getStaticPaths
 
-`getStaticPaths` can only be exported from a [dynamic route](/docs/routing/dynamic-routes.md) that also uses `getStaticProps`. You **cannot** export it from non-page files e.g. from your `components` folder.
-
-Note that you must use export `getStaticPaths` as a standalone function — it will **not** work if you add `getStaticPaths` as a property of the page component.
+- `getStaticPaths` **must** be used with `getStaticProps`
+- You **cannot** use `getStaticPaths` with [`getServerSideProps`](/docs/basic-features/data-fetching/get-server-side-props.md)
+- You can export `getStaticPaths` from a [Dynamic Route](/docs/routing/dynamic-routes.md) that also uses `getStaticProps`
+- You **cannot** export `getStaticPaths` from non-page file (e.g. your `components` folder)
+- You must export `getStaticPaths` as a standalone function, and not a property of the page component
 
 ## Runs on every request in development
 
 In development (`next dev`), `getStaticPaths` will be called on every request.
 
+## Generating paths on-demand
+
+`getStaticProps` allows you to control which pages are generated during the build instead of on-demand with [`fallback`](/docs/api-reference/data-fetching/get-static-paths.md#fallback-blocking). Generating more pages during a build will cause slower builds.
+
+You can defer generating all pages on-demand by returning an empty array for `paths`. This can be especially helpful when deploying your Next.js application to multiple environments. For example, you can have faster builds by generating all pages on-demand for previews (but not production builds). This is helpful for sites with hundreds/thousands of static pages.
+
+```jsx
+// pages/posts/[id].js
+
+export async function getStaticPaths() {
+  // When this is true (in preview environments) don't
+  // prerender any static pages
+  // (faster builds, but slower initial page load)
+  if (process.env.SKIP_BUILD_STATIC_GENERATION) {
+    return {
+      paths: [],
+      fallback: 'blocking',
+    }
+  }
+
+  // Call an external API endpoint to get posts
+  const res = await fetch('https://.../posts')
+  const posts = await res.json()
+
+  // Get the paths we want to prerender based on posts
+  // In production environments, prerender all pages
+  // (slower builds, but faster initial page load)
+  const paths = posts.map((post) => ({
+    params: { id: post.id },
+  }))
+
+  // { fallback: false } means other routes should 404
+  return { paths, fallback: false }
+}
+```
+
 ## Related
 
 For more information on what to do next, we recommend the following sections:

docs/basic-features/typescript.md

@@ -64,7 +64,7 @@ npm run dev
 
 You're now ready to start converting files from `.js` to `.tsx` and leveraging the benefits of TypeScript!
 
-> A file named `next-env.d.ts` will be created in the root of your project. This file ensures Next.js types are picked up by the TypeScript compiler. **You cannot remove it or edit it** as it can change at any time. As such this file should not be committed and should be ignored by version control.
+> A file named `next-env.d.ts` will be created at the root of your project. This file ensures Next.js types are picked up by the TypeScript compiler. **You should not remove it or edit it** as it can change at any time. This file should not be committed and should be ignored by version control (e.g. inside your `.gitignore` file).
 
 > TypeScript `strict` mode is turned off by default. When you feel comfortable with TypeScript, it's recommended to turn it on in your `tsconfig.json`.
 

docs/manifest.json

@@ -414,8 +414,10 @@
           "path": "/docs/api-reference/next/server.md"
         },
         {
-          "title": "next/streaming",
-          "path": "/docs/api-reference/next/streaming.md"
+          "path": "/docs/api-reference/next/streaming",
+          "redirect": {
+            "destination": "/docs/advanced-features/react-18"
+          }
         },
         {
           "title": "next/future/image (experimental)",

docs/testing.md

@@ -493,7 +493,6 @@ For further reading, you may find these resources helpful:
 
 The Next.js community has created packages and articles you may find helpful:
 
-- [next-page-tester](https://github.com/toomuchdesign/next-page-tester) for DOM Integration Testing.
 - [next-router-mock](https://github.com/scottrippey/next-router-mock) for Storybook.
 - [Test Preview Vercel Deploys with Cypress](https://glebbahmutov.com/blog/develop-preview-test/) by Gleb Bahmutov.