docs(nxdev): adjust syntax highlighting lang for javascript & typescript (#10152)

docs/generated/packages/angular.json

@@ -2158,7 +2158,7 @@
         "$schema": "http://json-schema.org/draft-07/schema",
         "title": "Schema for Webpack Browser",
         "description": "The webpack-browser executor is very similar to the standard browser builder provided by the Angular Devkit. It allows you to build your Angular application to a build artifact that can be hosted online. There are some key differences:   \n- Supports Custom Webpack Configurations  \n- Supports Incremental Building",
-        "examplesFile": "##### Using a custom webpack configuration\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```ts\n\"build\": {\n    \"executor\": \"@nrwl/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"customWebpackConfig\": {\n          \"path\": \"apps/appName/webpack.config.js\"\n        }\n    }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.  \n> You can read more about when to use incremental builds [here](/ci/incremental-builds#when-should-i-use-incremental-builds).\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```ts\n\"build\": {\n    \"executor\": \"@nrwl/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"buildLibsFromSource\": false\n    }\n}\n```\n",
+        "examplesFile": "##### Using a custom webpack configuration\n\nThe executor supports providing a path to a custom webpack configuration. This allows you to customize how your Angular application is built. It currently supports the following types of webpack configurations:\n\n- `object`\n- `Function`\n- `Promise<object|Function>`\n\nThe executor will merge the provided configuration with the webpack configuration that Angular Devkit uses. The merge order is:\n\n- Angular Devkit Configuration\n- Provided Configuration\n\nTo use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n    \"executor\": \"@nrwl/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"customWebpackConfig\": {\n          \"path\": \"apps/appName/webpack.config.js\"\n        }\n    }\n}\n```\n\n##### Incrementally Building your Application\n\nThe executor supports incrementally building your Angular application by building the workspace libraries it depends on _(that have been marked as buildable)_ and then building your application using the built source of the libraries.\n\nThis can improve build time as the building of the workspace libraries can be cached, meaning they only have to be rebuilt if they have changed.\n\n> Note: There may be some additional overhead in the linking of the built libraries' sources which may reduce the overall improvement in build time. Therefore this approach only benefits large applications and would likely have a negative impact on small and medium applications.  \n> You can read more about when to use incremental builds [here](/ci/incremental-builds#when-should-i-use-incremental-builds).\n\nTo allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:\n\n```typescript\n\"build\": {\n    \"executor\": \"@nrwl/angular:webpack-browser\",\n    \"options\": {\n        ...\n        \"buildLibsFromSource\": false\n    }\n}\n```\n",
         "type": "object",
         "presets": [
           {

docs/shared/generators/generator-options.md

@@ -156,7 +156,7 @@ The property keys that are required. Example:
 In this example, the property `name` is required, while the property `type` is optional.
 You can define your TypeScript schema like this:
 
-```ts
+```typescript
 interface Schema {
   name: string; // required
   type?: string; // optional
@@ -603,7 +603,7 @@ Reference to a schema. Examples can be seen in the [`definitions`](#definitions)
 
 The default source of this property. The full declaration of `$default` is:
 
-```ts
+```typescript
 // with ? - optional
 // without ? - required
 // | - or
@@ -655,7 +655,7 @@ See [the above `additionalProperties` section](#additionalproperties).
 
 Prompt and help user to input the value of the property. It can be a `string` or a `object`. The full declaration is:
 
-```ts
+```typescript
 // with ? - optional
 // without ? - required
 // | - or
@@ -696,7 +696,7 @@ The type of the prompt.
 
 The choice of the prompt. The `x-prompt.type` must be `list`. The declaration of `items` is:
 
-```ts
+```typescript
 // with ? - optional
 // without ? - required
 // | - or

docs/shared/guides/adding-assets.md

@@ -40,7 +40,7 @@ This method of import allow you to work with the SVG the same way you would with
 
 Note that if you are using Next.js, you have to opt into this behavior. To import SVGs as React components with Next.js, you need to make sure that `nx.svgr` value is set to `true` in your Next.js application's `next.config.js` file:
 
-```js
+```javascript
 module.exports = withNx({
   nx: {
     svgr: true,

docs/shared/guides/module-federation/dynamic-mfe-angular.md

@@ -54,7 +54,7 @@ We’ll start by creating this file. Add a `mfe.manifest.json` file to the `src/
 
 Next, open `main.ts` under the `src/`folder and replace it with the following:
 
-```ts
+```typescript
 import { setRemoteDefinitions } from '@nrwl/angular/mfe';
 
 fetch('/assets/mfe.manifest.json')
@@ -75,7 +75,7 @@ At the moment, webpack is statically building our application, telling it at bui
 
 Open the `mfe.config.js` file at the root of our `apps/dashboard/` folder and set the `remotes` property to be an empty array. It should look like this:
 
-```js
+```javascript
 module.exports = {
   name: 'dashboard',
   remotes: [],
@@ -86,7 +86,7 @@ Next, we need to change how our application attempts to load the Remote when it
 
 You should see the following line in the `RouterModule.forRoot()`:
 
-```ts
+```typescript
 {
     path: 'login',
     loadChildren: () =>
@@ -96,7 +96,7 @@ You should see the following line in the `RouterModule.forRoot()`:
 
 Replace it with the following:
 
-```ts
+```typescript
 {
     path: 'login',
     loadChildren: () =>
@@ -108,7 +108,7 @@ Replace it with the following:
 
 You will also need to add the following import to the top of the file:
 
-```ts
+```typescript
 import { loadRemoteModule } from '@nrwl/angular/mfe';
 ```
 

docs/shared/guides/module-federation/faster-builds.md

@@ -117,7 +117,7 @@ In the future, Nx may automatically handle this for you.
 
 The webpack configuration uses an utility function that Nx provides: `withModuleFederation`.
 
-```js
+```javascript
 // For Angular, you'll see `@nrwl/angular/module-federation`
 const withModuleFederation = require('@nrwl/react/module-federation');
 const moduleFederationConfig = require('./module-federation.config');
@@ -133,7 +133,7 @@ We'll talk about [what `withModuleFederation` does](#what-does-withmodulefederat
 
 This file is the main configuration for the `shell`, and you'll see `module-federation.config.js` for the generated remotes as well.
 
-```js
+```javascript
 module.exports = {
   name: 'shell',
   remotes: ['shop', 'cart', 'about'],
@@ -157,7 +157,7 @@ With Nx, the developer experience (DX) when working with Module Federation match
 
 If you want to opt-out of the shared, singleton behavior of libraries you can use the `shared: (libraryName, sharedConfig) => sharedConfig)` option in `module-federation.config.js`.
 
-```js
+```javascript
 module.exports = {
   name: 'shell',
   remotes: ['shop', 'cart', 'about'],
@@ -229,7 +229,7 @@ First, make sure you have implicit dependencies from `shell` to each remote. In
 
 Next, open up the production webpack configuration file and update the remote URLs to their own subfolder under `http://localhost:3000`.
 
-```js
+```javascript
 // apps/shell/webpack.config.prod.js
 const withModuleFederation = require('@nrwl/react/module-federation');
 const moduleFederationConfig = require('./module-federation.config');

docs/shared/guides/react-native.md

@@ -266,7 +266,7 @@ NX_BUILD_NUMBER=123
 
 Then access variables defined there from your app:
 
-```js
+```javascript
 import Config from 'react-native-config';
 
 Config.NX_BUILD_NUMBER; // '123'

docs/shared/guides/storybook/migrate-webpack-final-angular.md

@@ -9,7 +9,7 @@ Here are the main differences to the previous setups:
 
 Here's an example of a newly generated `main.js` file:
 
-```js
+```javascript
 // project-level .storybook/main.js file
 const rootMain = require('../../../.storybook/main');
 
@@ -39,7 +39,7 @@ module.exports = {
 
 At the Nx workspace root level, the configuration file looks as follows:
 
-```js
+```javascript
 // root level .storybook/main.js file
 module.exports = {
   stories: [],
@@ -68,7 +68,7 @@ Restructure your `main.js` file s.t. it looks like in the example illustrated ab
 
 If you need to keep your root-level `.storybook/webpack.config.js` for now, then make sure you adjust the `main.js` in a way that it properly calls the root-level `webpack.config.js` to inherit all of the global configurations.
 
-```js
+```javascript
 const rootMain = require('../../../.storybook/main');
 const rootWebpackConfig = require('../../../.storybook/webpack.config');
 
@@ -94,7 +94,7 @@ module.exports = {
 
 In previous versions of Nx a custom `webpack.config.js` was generated with the following content:
 
-```js
+```javascript
 const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');
 const rootWebpackConfig = require('../../../.storybook/webpack.config');
 /**

docs/shared/guides/storybook/migrate-webpack-final-react.md

@@ -11,7 +11,7 @@ Here are the main differences to the previous versions of Nx:
 
 Here's an example of a newly generated `main.js` file:
 
-```js
+```javascript
 // project-level .storybook/main.js file
 const rootMain = require('../../../.storybook/main');
 
@@ -45,7 +45,7 @@ module.exports = {
 
 At the Nx workspace root level, the configuration file looks as follows:
 
-```js
+```javascript
 // root level .storybook/main.js file
 module.exports = {
   stories: [],
@@ -74,7 +74,7 @@ Restructure your `main.js` file s.t. it looks like in the example illustrated ab
 
 If you need to keep your root-level `.storybook/webpack.config.js` for now, then make sure you adjust the `main.js` in a way that it properly calls the root-level `webpack.config.js` to inherit all of the global configurations.
 
-```js
+```javascript
 const rootMain = require('../../../.storybook/main');
 const rootWebpackConfig = require('../../../.storybook/webpack.config');
 
@@ -100,7 +100,7 @@ module.exports = {
 
 In previous versions of Nx a custom `webpack.config.js` was generated with the following content:
 
-```js
+```javascript
 module.exports = async ({ config, mode }) => {
   config = await rootWebpackConfig({ config, mode });
 

docs/shared/guides/storybook/plugin-react.md

@@ -72,7 +72,7 @@ The project-specific Storybook configuration is pretty much similar what you wou
 
 `@nrwl/react` ships with a Storybook preset to make sure it uses the very same configuration as your Nx React application. When you generate a Storybook configuration for a project, it'll automatically add the preset to your configuration.
 
-```ts
+```typescript
 const rootMain = require('../../../.storybook/main');
 
 module.exports = {

docs/shared/guides/storybook/storybook-composition-setup.md

@@ -17,7 +17,7 @@ All you need is a URL of a live Storybook, and a "host" Storybook. In the `.stor
 
 In the example below, we have a host Storybook running on local port 4400 (http://localhost:4400) - not displayed here. In it, we want to compose three other Storybooks. The "one-composed" and "two-composed", running on local ports `4401` and `4402` accordingly, as well as the [Storybook website's Storybook](https://next--storybookjs.netlify.app/official-storybook) which is live on the address that you see.
 
-```js
+```javascript
 // .storybook/main.js of our Host Storybook - assuming it's running on port 4400
 module.exports = {
   ...,
@@ -93,7 +93,7 @@ of our projects runs on which port. The problem that this creates is that we wil
 
 Now, we need to add to our host project's `main.js` file (the path of which would be `apps/main-host/.storybook/main.js`) a `refs` object, to configure our composition. An example of such a configuration looks like this:
 
-```js
+```javascript
 module.exports = {
   ...,
   refs: {

docs/shared/guides/using-tailwind-css-in-react.md

@@ -25,7 +25,7 @@ This creates the required files with a general boilerplate implementation.
 
 Next, adjust the `postcss.config.js` as follows:
 
-```js
+```javascript
 const { join } = require('path');
 
 module.exports = {
@@ -48,7 +48,7 @@ Nx has a utility function that can be used to construct the glob representation
 
 The function receives a directory path that is used to identify the project for which the dependencies are going to be identified (therefore it needs to be a directory path within a project). It can also receive an optional glob pattern to append to each dependency source root path to conform the final glob pattern. If the glob pattern is not provided, it will default to `/**/!(*.stories|*.spec).{ts,html}`.
 
-```js
+```javascript
 // apps/app1/tailwind.config.js
 const { createGlobPatternsForDependencies } = require('@nrwl/react/tailwind');
 const { join } = require('path');

docs/shared/guides/webpack-5.md

@@ -40,7 +40,7 @@ generator. They both install the same packages and are interchangeable.
 As of Next.js 11 and Nx 12.6.0, Webpack 5 is the default version used. Check your `next.config.js` file to ensure it is
 enabled.
 
-```js
+```javascript
 // eslint-disable-next-line @typescript-eslint/no-var-requires
 const withNx = require('@nrwl/next/plugins/with-nx');
 

docs/shared/jest-plugin.md

@@ -123,7 +123,7 @@ By default, coverage reports will be generated in the `coverage/` directory unde
 In order to use Jest's global setup/teardown functions that reference nx libraries, you'll need to register the TS path for jest to resolve the libraries.
 Nx provides a helper function that you can import within your setup/teardown file.
 
-```ts
+```typescript
 import { registerTsProject } from 'nx/src/utils/register';
 const cleanupRegisteredPaths = registerTsProject('.', 'tsconfig.base.json');
 

docs/shared/using-executors.md

@@ -257,7 +257,7 @@ export default async function (opts) {
 
 You can use the [`rxjs-for-await`](https://www.npmjs.com/package/rxjs-for-await) library to convert an `Observable` into an async iterable.
 
-```ts
+```typescript
 import { of } from 'rxjs';
 import { eachValueFrom } from 'rxjs-for-await';
 

packages/angular/docs/webpack-browser-examples.md

@@ -13,7 +13,7 @@ The executor will merge the provided configuration with the webpack configuratio
 
 To use a custom webpack configuration when building your Angular application, change the `build` target in your `project.json` to match the following:
 
-```ts
+```typescript
 "build": {
     "executor": "@nrwl/angular:webpack-browser",
     "options": {
@@ -36,7 +36,7 @@ This can improve build time as the building of the workspace libraries can be ca
 
 To allow your Angular application to take advantage of incremental building, change the `build` target in your `project.json` to match the following:
 
-```ts
+```typescript
 "build": {
     "executor": "@nrwl/angular:webpack-browser",
     "options": {