Update dependencies + quick fixes

layout/MDXLayoutNav.tsx

@@ -123,6 +123,10 @@ const MobileWrapper = ({ title, children }: PropsWithChildren<{ title?: string }
   )
 }
 
+const DocSearchHit = ({ hit, children }: PropsWithChildren<{ hit: { url: string } }>) => (
+  <Link href={removeBasePathFromUrl(hit.url)}>{children}</Link>
+)
+
 export const MDXLayoutNav = ({ mobile = false }: { mobile?: boolean }) => {
   const router = useRouter()
   const { navItems, currentPage } = useContext(NavContext)!
@@ -147,7 +151,7 @@ export const MDXLayoutNav = ({ mobile = false }: { mobile?: boolean }) => {
               url: item.url.replace('https://thegraph.com/docs', process.env.BASE_PATH ?? ''),
             }))
           }}
-          hitComponent={({ hit, children }) => <Link href={removeBasePathFromUrl(hit.url)}>{children}</Link>}
+          hitComponent={DocSearchHit}
           navigator={{
             navigate({ itemUrl }) {
               void router.push(removeBasePathFromUrl(itemUrl))
@@ -178,7 +182,7 @@ export const MDXLayoutNav = ({ mobile = false }: { mobile?: boolean }) => {
               }
               if ('children' in navItem) {
                 return (
-                  <NavTree.Group active={currentPage?.path.startsWith(navItem.path)}>
+                  <NavTree.Group active={currentPage?.path.startsWith(`${navItem.path}/`)}>
                     <NavTree.Group.Heading
                       sx={mobile ? { py: 0 } : {}}
                       buttonProps={{ sx: mobile ? {} : { paddingInlineEnd: 0 } }}

lib/remarkMdxLayout.mjs

@@ -4,7 +4,7 @@ import process from 'process'
 import { slugifyWithCounter } from '@sindresorhus/slugify'
 import { Parser } from 'acorn'
 import acornJsx from 'acorn-jsx'
-import { merge } from 'lodash-es'
+import lodash from 'lodash'
 import { Serializer } from 'serialize-as-code'
 import { visit } from 'unist-util-visit'
 
@@ -79,7 +79,7 @@ export const remarkMdxLayout = () => {
 
       const headingId = slugify(headingText) || `heading-${headingCount}`
 
-      heading.data = merge(heading.data, {
+      heading.data = lodash.merge(heading.data, {
         hProperties: {
           id: headingId,
         },

navigation/navigation.ts

@@ -149,8 +149,8 @@ export const navigation = (locale: AppLocale): NavItemDefinition[] => [
     slug: 'indexing',
     children: [
       {
-        slug: 'operating-graph-node'
-      }
+        slug: 'operating-graph-node',
+      },
     ],
   },
   {

package.json

@@ -21,7 +21,7 @@
   },
   "dependencies": {
     "@docsearch/react": "^3.3.0",
-    "@edgeandnode/components": "^24.0.5",
+    "@edgeandnode/components": "^24.0.7",
     "@emotion/react": "^11.10.5",
     "@mdx-js/loader": "^2.1.5",
     "@mdx-js/react": "^2.1.5",
@@ -30,7 +30,7 @@
     "@radix-ui/react-popover": "^1.0.2",
     "@radix-ui/react-visually-hidden": "^1.0.1",
     "@reach/auto-id": "^0.18.0",
-    "lodash-es": "^4.17.21",
+    "lodash": "^4.17.21",
     "next": "^12.3.4",
     "next-seo": "^5.14.1",
     "prism-react-renderer": "^1.3.5",
@@ -47,15 +47,15 @@
     "@sindresorhus/slugify": "^2.1.1",
     "@svgr/webpack": "^6.5.1",
     "@types/color": "^3.0.3",
-    "@types/lodash-es": "^4.17.6",
-    "@types/node": "^16.18.3",
+    "@types/lodash": "^4.14.191",
+    "@types/node": "^16.18.4",
     "@types/react": "^17.0.52",
     "@types/react-dom": "^17.0.18",
     "acorn": "^8.8.1",
     "acorn-jsx": "^5.3.2",
     "eslint": "^8.28.0",
     "husky": "^8.0.2",
-    "lint-staged": "^13.0.3",
+    "lint-staged": "^13.0.4",
     "path": "^0.12.7",
     "prettier": "^2.8.0",
     "remark-frontmatter": "^4.0.1",

pages/_app.tsx

@@ -1,4 +1,4 @@
-import { merge } from 'lodash-es'
+import merge from 'lodash/merge'
 import { AppProps } from 'next/app'
 import Head from 'next/head'
 import NextLink from 'next/link'

pages/en/indexing/operating-graph-node.mdx

@@ -10,7 +10,7 @@ This provides a contextual overview of Graph Node, and some of the more advanced
 
 [Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
 
-Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node). As well 
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
 
 #### PostgreSQL database
 
@@ -150,6 +150,7 @@ Graph Node indexing can scale horizontally, running multiple instances of Graph
 Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
 
 Example deployment rule configuration:
+
 ```toml
 [deployment]
 [[deployment.rule]]
@@ -215,6 +216,7 @@ ingestor = "block_ingestor_node"
 ### Supporting multiple networks
 
 The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
 - Multiple networks
 - Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
 - Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
@@ -283,13 +285,15 @@ The full schema is available [here](https://github.com/graphprotocol/graph-node/
 ### Indexing performance
 
 There are three separate parts of the indexing process:
+
 - Fetching events of interest from the provider
 - Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
 - Writing the resulting data to the store
 
 These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
 
 Common causes of indexing slowness:
+
 - Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
 - Making large numbers of `eth_calls` as part of handlers
 - A large amount of store interaction during execution
@@ -322,8 +326,8 @@ If a block cache inconsistency is suspected, such as a tx receipt missing event:
 
 1. `graphman chain list` to find the chain name.
 2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
-    1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
-    2. If the block matches the provider, then the issue can be debugged directly against the provider.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
 
 ### Querying issues and errors
 

pages/en/network-transition-faq.mdx

@@ -6,7 +6,7 @@ Developers will have plenty of time to migrate their subgraphs to the decentrali
 
 Each chain on the hosted service, including Ethereum, will sunset gradually as it is supported on the decentralized network to achieve feature parity and a high quality of service. This will happen on a chain-to-chain basis with help from Indexers in the [MIPs program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program/), to enable full support for each chain on the decentralized network.
 
-To add more clarity around continued support for each chain on the hosted service, these FAQs answer common questions regarding the specifics of the network transition process. If you would like to start the subgraph migration process now, here is a [step-by-step guide](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph). To skip to the migration FAQ, [click here](#migration-fa-qs-answers-to-common-questions).
+To add more clarity around continued support for each chain on the hosted service, these FAQs answer common questions regarding the specifics of the network transition process. If you would like to start the subgraph migration process now, here is a [step-by-step guide](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph). To skip to the migration FAQ, [click here](#migration-faqs).
 
 ## Hosted Service Sunset FAQs