Merge branch 'main' into mk/no-beta

Author: kodiakhq[bot]

demos/default/netlify.toml

@@ -1,7 +1,7 @@
 [build]
 command = "next build"
 publish = ".next"
-ignore = "echo CACHED_COMMIT_REF: $CACHED_COMMIT_REF COMMIT_REF: $COMMIT_REF && git diff --exit-code $CACHED_COMMIT_REF $COMMIT_REF ../../"
+ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF ../../"
 
 [build.environment]
 # cache Cypress binary in local "node_modules" folder

demos/nx-next-monorepo-demo/netlify.toml

@@ -1,7 +1,7 @@
 [build]
 command = "npm run build"
 publish = "dist/apps/demo-monorepo/.next"
-ignore = "git diff --exit-code $CACHED_COMMIT_REF $COMMIT_REF ../../"
+ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF ../../"
 
 [dev]
 command = "npm run start"

demos/nx-next-monorepo-demo/package-lock.json

@@ -34,9 +34,9 @@
     "@types/node": "16.11.12",
     "@types/react": "17.0.37",
     "@types/react-dom": "17.0.11",
-    "@typescript-eslint/eslint-plugin": "~4.33.0",
-    "@typescript-eslint/parser": "~4.33.0",
-    "babel-jest": "27.4.2",
+    "@typescript-eslint/eslint-plugin": "~5.6.0",
+    "@typescript-eslint/parser": "~5.6.0",
+    "babel-jest": "27.4.4",
     "cypress": "^8.3.0",
     "eslint": "8.4.1",
     "eslint-config-next": "12.0.7",
@@ -46,7 +46,7 @@
     "eslint-plugin-jsx-a11y": "6.5.1",
     "eslint-plugin-react": "7.26.1",
     "eslint-plugin-react-hooks": "4.3.0",
-    "jest": "27.4.3",
+    "jest": "27.4.4",
     "prettier": "^2.3.1",
     "ts-jest": "27.1.1",
     "typescript": "~4.5.0",

demos/nx-next-monorepo-demo/package.json

@@ -1,7 +1,7 @@
 [build]
 command = "next build"
 publish = ".next"
-ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF . ../../"
+ignore = "git diff --quiet $CACHED_COMMIT_REF $COMMIT_REF ../../"
 
 [build.environment]
 # cache Cypress binary in local "node_modules" folder

demos/static-root/netlify.toml

@@ -0,0 +1,47 @@
+## Incremental Static Regeneration (ISR)
+
+[Incremental static regeneration](https://vercel.com/docs/concepts/next.js/incremental-static-regeneration) is a feature
+of Next.js that allows pages to be updated after a site has been built and deployed. It is now fully supported in
+Netlify by the Essential Next.js plugin, meaning large sites can update pages without needing to rebuild the entire
+site. Unlike server-side rendered pages, the page is not rebuilt for each user, so they load quickly, but unlike
+statically-generated pages they can be periodically updated with new content without a new deploy.
+
+### Using ISR on Netlify
+
+ISR on Netlify is implemented with [On Demand Builders](https://docs.netlify.com/configure-builds/on-demand-builders/),
+using the TTL feature. You can enable ISR for a page by returning a value for `revalidate` from the `getStaticProps`
+function. This value is the number of seconds for which the content will be considered fresh. If a request arrives for a
+page after the `revalidate` period has elapsed, the page will be regenerated. ISR uses a "stale while revalidate"
+strategy, meaning that the visitor still receives the stale content, but it is regenerated in the background ready for
+the next request. The generated page is persisted globally, so is available to all visitors wherever they are in the
+world. It is also cached in the global Netlify CDN so responses are fast.
+
+The minimum value for `revalidate` is 60 seconds, and any value less than that will be rounded-up to 60 seconds. After a
+request is made for stale content, the page will be regenerated in the background and immediately persisted globally,
+but it can take up to 60 seconds before the new content is then updated in all CDN nodes if they already had a cached
+copy.
+
+If a new deploy is made, all persisted pages and CDN cached pages will be invalidated so that conflicts are avoided. If
+this did not happen, a stale HTML page might make a request for an asset that no longer exists in the new deploy. By
+invalidating all persisted pages, you can be confident that this will never happen and that deploys remain atomic.
+
+### Alternatives to ISR
+
+ISR is best for situations where there are regular updates to content throughout the day, particularly you don't have
+control over when it happens. It is less ideal in situations such as a CMS with incremental updates where you can have
+the CMS trigger a deploy when a page is added or edited. This offers the best performance and avoids unnecesary
+rebuilds.
+
+### Static site generation
+
+For high-traffic pages you can use
+[static generation](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation) without
+`revalidate`, which deploys static files directly to the CDN for maximum performance.
+
+### Distributed persistent rendering
+
+For less commonly-accessed content you can use return `fallback: "blocking"` from
+[`getStaticPaths`](https://nextjs.org/docs/basic-features/data-fetching#getstaticpaths-static-generation) and defer
+builds until the first request. This also uses On Demand Builders, but persists the built page until the next deploy.
+This is great for long-tail content and archives that don't change often but are not accessed often enough to justify
+statically-generating them at build time.