misc(website): Update dependencies (#11895)

Summary:
Ran "npm update --save" to update the dependencies. The dependencies were out of date with security vulnerabilities so it is best to update them to the latest versions.
The commit also fixes syntax errors in markdown that caused build failures with the new versions.

Pull Request resolved: #11895

Reviewed By: kagamiori

Differential Revision: D69496721

Pulled By: kgpai

fbshipit-source-id: 597e844ac30d5f270b16bfdd982bd70dd5bd0110

website/blog/2022-10-31-simple-1.mdx

@@ -64,7 +64,7 @@ In the code above, the overhead of checking the encoding is switched outside the
 One issue with this optimization is that the core loop is replicated many times. In general, the numbers of times it will be replicated
 is `n^m` where `n` is the number of args, and `m` is the number of encodings.
 
-To avoid code size blowing, we only apply this optimization when all input arguments are primitives and the number of input arguments is <=3.
+To avoid code size blowing, we only apply this optimization when all input arguments are primitives and the number of input arguments is \<=3.
 The figure below shows the effect of this optimization on the processing time of a query of primitive operations (the expression is a common pattern in ML use cases).
 
 <figure>

website/blog/2023-05-01-simple-2.mdx

@@ -62,7 +62,7 @@ The reason the simple is faster than the vector for some benchmarks is because w
 ### Writer types for outputs
 
 
-A similar pattern of inefficiency existed for functions with complex output types. The graph below shows the previous path of writing complex types through the simple function interface. In the previous  path, for each row, the result is first written to a temporary object (std::vector, folly::f14FastMap<\>, etc.), then serialized into the Velox vector.
+A similar pattern of inefficiency existed for functions with complex output types. The graph below shows the previous path of writing complex types through the simple function interface. In the previous  path, for each row, the result is first written to a temporary object (std::vector, folly::f14FastMap\<\>, etc.), then serialized into the Velox vector.
 <figure>
  <img src="/img/simple1_5.png"/>
 </figure>
@@ -80,17 +80,17 @@ outerArray is an array writer and whenever push_back is called, the underlying v
 
 **In order & final elements writing**: Unlike the previous interface, the new writer interface needs to write things in order, since it directly serializes elements into Velox vector buffers. Written elements also can not be modified.
 
-For example, for a function with an Array<Map\> output , we can't add three maps, and write to them concurrently. The new interface should enforce that one map is written completely before the next one starts. This is because we are serializing things directly in the map vector, and to determine the offset of the new map we need first to know the end offset of the previous one.
+For example, for a function with an Array\<Map\> output , we can't add three maps, and write to them concurrently. The new interface should enforce that one map is written completely before the next one starts. This is because we are serializing things directly in the map vector, and to determine the offset of the new map we need first to know the end offset of the previous one.
 
-The code below shows a function with Array<Map\> output:
+The code below shows a function with Array\<Map\> output:
 <figure>
  <img src="/img/simple1_code2.png"/>
 </figure>
 
 **Compatibility with std::like containers.**: Unfortunately, the new interface is not completely compatible with std::like interfaces, in fact, it deviates syntactically and semantically (for example a std::map enforces unique keys and ordering of elements) while map writer does not.
-When the element type is primitive (ex: Array<int\>) we enable std::like APIs (push_back, emplace()).
+When the element type is primitive (ex: Array\<int\>) we enable std::like APIs (push_back, emplace()).
 
-But we can not do that for nested complex types (ex:Array<Array<int\>\>) since it breaks the in-order & final elements writing rule mentioned above.
+But we can not do that for nested complex types (ex:Array\<Array\<int\>\>) since it breaks the in-order & final elements writing rule mentioned above.
 
 The figure below shows the performance gain achieved by this change, functions' performance is evaluated before and after the change.
 <figure>

website/blog/2023-07-19-array-sort.mdx

@@ -108,7 +108,7 @@ This is longer and harder to read, but the result array is sorted properly. The
 comparator says that null is greater than any other value, so null is placed at the
 end of the array.
 
-Note: When (x, y) return -1, the algorithm assumes that x <= y.
+Note: When (x, y) return -1, the algorithm assumes that x \<= y.
 
 
 Writing comparators correctly is not easy. Writing comparators that handle null inputs

website/docusaurus.config.js

@@ -1,8 +1,8 @@
 // @ts-check
 // Note: type annotations allow type checking and IDEs autocompletion
 
-const lightCodeTheme = require('prism-react-renderer/themes/github');
-const darkCodeTheme = require('prism-react-renderer/themes/dracula');
+const lightCodeTheme = require('prism-react-renderer').themes.github;
+const darkCodeTheme = require('prism-react-renderer').themes.dracula;
 
 /** @type {import('@docusaurus/types').Config} */
 const config = {
@@ -34,13 +34,10 @@ const config = {
       ({
         docs: {
           sidebarPath: require.resolve('./sidebars.js'),
-          // Please change this to your repo.
-          // Remove this to remove the "edit this page" links.
         },
         blog: {
           showReadingTime: true,
-          // Please change this to your repo.
-          // Remove this to remove the "edit this page" links.
+          onUntruncatedBlogPosts: 'ignore',
         },
         theme: {
           customCss: require.resolve('./src/css/custom.css'),