[WIP] Drop node manifests

.circleci/config.yml

@@ -238,12 +238,6 @@ jobs:
       - e2e-test:
           test_path: integration-tests/gatsby-source-wordpress
 
-  integration_tests_node_manifest:
-    executor: node
-    steps:
-      - e2e-test:
-          test_path: integration-tests/node-manifest
-
   integration_tests_long_term_caching:
     executor: node
     steps:
@@ -392,6 +386,7 @@ jobs:
       image: "18.12.0"
     steps:
       - checkout
+      - run: npm i -g pnpm@latest-9
       - run: ./scripts/assert-changed-files.sh "packages/*|.circleci/*"
       - <<: *attach_to_bootstrap
       - run:
@@ -681,8 +676,6 @@ workflows:
             - bootstrap
       - integration_tests_gatsby_source_wordpress:
           <<: *e2e-test-workflow
-      - integration_tests_node_manifest:
-          <<: *e2e-test-workflow
       - integration_tests_long_term_caching:
           <<: *e2e-test-workflow
       - integration_tests_cache_resilience:

docs/docs/conceptual/content-sync.md

@@ -26,17 +26,6 @@ In the case that your content lives on multiple pages, for example a blog post p
 
 You will not need to do this if you're building pages using the [File System Route API][fsroutesapi], or if your page context includes a matching `id` property. See the next section for more info on this.
 
-## Node to Page Mapping Hierarchy
-
-Content Sync uses the [`unstable_createNodeManifest`][createnodemanifest] API via source plugins to allow source plugins to tell Gatsby which nodes are being previewed. When this public action is called, Gatsby uses an internal hierarchy to determine which page the content author intends to preview.
-
-The hierarchy is as follows, from most specific to least specific:
-
-1. [The`ownerNodeId` property in the `createPage` action][createpage]. (This is set manually by the Gatsby site developer)
-2. Nodes associated with pages created from the [File System Route API][fsroutesapi]. (automatic)
-3. An `id` property in the [page `context` passed to the `createPage` API][createpage] with a node id which matches the previewed node id. (automatic)
-4. The first matching node id found in Gatsby's [GraphQL query tracking][querytracking] which maps node id's to pages that query them. This allows nodes which have no direct top-level page correlated with them to be previewed throughout the site. (automatic)
-
 ## Source Plugin Authors
 
 If you're a source plugin author, you can find instructions on adding Content Sync support to your source plugin and CMS extension in the [source plugin author docs](https://www.gatsbyjs.com/docs/how-to/plugins-and-themes/creating-a-source-plugin/).
@@ -46,7 +35,6 @@ If you're a source plugin author, you can find instructions on adding Content Sy
 ![Diagram of Content Sync on Gatsby Cloud. When a user clicks "Open Preview" the manifest id is created from the CMS and sent to Gatsby Cloud. The Content Sync UI then displays a loading state while it checks for a matching manifest id in Gatsby build public directory. At the same time a request is send to the preview webhook and Gatsby Cloud starts a build. If it finds a matching manifest id created from the CMS Gatsby maps data to correct page for preview and adds the manifest file to the build public directory. Now the Gatsby Cloud Preview Runner detects a node manifest to preview and redirects to the preview itself.](../images/content-sync-diagram.png)
 
 [authordocs]: /docs/how-to/plugins-and-themes/creating-a-source-plugin/#enabling-content-sync
-[createnodemanifest]: /docs/reference/config-files/actions#unstable_createNodeManifest
 [createpage]: /docs/reference/config-files/actions#createPage
 [querytracking]: /docs/page-node-dependencies/
 [fsroutesapi]: /docs/reference/routing/file-system-route-api/

docs/docs/reference/release-notes/v3.7/index.md

@@ -11,7 +11,6 @@ Key highlights of this release:
 - [Functions](#functions) - Now generally available
 - [webpack caching](#webpack-caching) - Starting gradual rollout
 - [Yarn 2 (PNP) support](#yarn-2-pnp-support)
-- [New API for source plugins: `createNodeManifest`](#new-api-for-source-plugins-createnodemanifest)
 - [Experimental: Node persistence in LMDB](#experimental-node-persistence-in-lmdb) - Lower peak memory usage
 - [`gatsby-remark-images`: async image decoding by default](#gatsby-remark-images-async-image-decoding-by-default)
 
@@ -42,25 +41,6 @@ behind a flag. Now we are starting a gradual rollout for everyone. This release
 
 If you encounter any issues, please let us know in the [umbrella discussion](https://github.com/gatsbyjs/gatsby/discussions/31525).
 
-## New API for source plugins: `createNodeManifest`
-
-This new API will be used to write out information that ties the state of some CMS content to a finally built page.
-Useful for routing to previews or even production content once they're built.
-
-This release adds a new public action `unstable_createNodeManifest` which is used to tie a manifest ID
-(a CMS id that maps to a unique revision state of some content) to a page that was built from a specific node.
-
-To make the mapping from node to page more accurate, this release introduces a new argument to the `createPage` helper,
-`ownerNodeId` so that a user can specify that a page is owned by a specific node.
-
-In the case that no `ownerNodeId` is provided, the logic checks for a page with an `id` variable in page context that
-matches to the node id of the node manifest. If neither of those exist the logic maps the manifest to the first
-page the node is found on in query tracking.
-
-The result is that a source plugin can allow a CMS to create a manifest file using a CMS ID that maps to a finally built page in Gatsby, allowing for a service to redirect to the right page after a build is complete.
-
-[Original PR](https://github.com/gatsbyjs/gatsby/pull/31127).
-
 ## Experimental: Node persistence in LMDB
 
 This release introduces a new experimental data storage option: LMDB (via the excellent [lmdb-store](https://github.com/DoctorEvidence/lmdb-store) package).

docs/docs/tutorial/creating-a-source-plugin/part-7/index.mdx

@@ -176,7 +176,6 @@ Here are some things to keep in mind and some "gotchas" depending on how the CMS
 
 - Inside the CMS, sometimes you will need to wait to make sure you have the correct `updatedAt` timestamp as some CMS may take a second to update their backend and then wait for the change to propagate to the frontend. While others will immediately update the frontend and then propagate that to the backend. You will need the _most_ up to date timestamp when opening the Content Sync UI waiting room.
 - Make sure that a preview webhook is being sent to Gatsby Cloud after the content is edited, whether it's before you press the "Open Preview" button or the "Open Preview" is the trigger that sends the webhook.
-- The node manifests get written out in the `public` dir of your gatsby site, so you can check the manifests on your local disk at `/public/__node-manifests/<sourcePluginName>/<manifestId>.json` or you can navigate directly to that piece of content `https://<your-domain>/__node-manifests/<sourcePluginName>/<manifestId>`.
 
 ## MIME types