docs(nx-dev): add missing blog description fields

docs/blog/2021-10-14-step-by-step-guide-on-creating-a-monorepo-for-react-native-apps-using-nx.md

@@ -4,6 +4,7 @@ slug: 'step-by-step-guide-on-creating-a-monorepo-for-react-native-apps-using-nx'
 authors: ['Emily Xiong']
 cover_image: '/blog/images/2021-10-14/92uzyqB8oJ8tZJB9wAdoWQ.png'
 tags: [nx, tutorial]
+description: A comprehensive tutorial on setting up a monorepo with Nx to create and manage both React Native mobile apps and React web apps, featuring code sharing through shared libraries and a practical example of building a daily horoscope application.
 ---
 
 Do you want to have both mobile and web apps in the same repo? Do you wish that you could share code between mobile and web apps? This blog post shows you how to create a React Native mobile app and a React web app in the same repo with shared libraries using Nx.
@@ -66,7 +67,7 @@ npm install --save @rneui/base @rneui/themed react-native-vector-icons react-nat
 _**yarn add @rneui/base @rneui/themed react-native-vector-icons react-native-safe-area-context
 ```
 
-In the app’s package.json at `apps/daily-horoscope-app/package.json`, under dependencies, add the above packages:
+In the app's package.json at `apps/daily-horoscope-app/package.json`, under dependencies, add the above packages:
 
 ```json5
 {
@@ -166,7 +167,7 @@ export enum AdhZodiacSign {
 }
 ```
 
-**Note**: the enum has a prefix “Adh” to indicate it is a model under domain “aztro-daily-horoscope”. Add this prefix to distinguish model names from component names.
+**Note**: the enum has a prefix "Adh" to indicate it is a model under domain "aztro-daily-horoscope". Add this prefix to distinguish model names from component names.
 
 This example uses icons from [Material Community Icons](https://materialdesignicons.com/). You need to create a list that contains the zodiac sign name and its matching icon.
 
@@ -542,7 +543,7 @@ npm install --save-dev redux-logger @types/redux-logger
 yarn add redux-logger @types/redux-logger --dev
 ```
 
-Then you need to add the redux-logger to the root store’s middleware, so the rootStore becomes:
+Then you need to add the redux-logger to the root store's middleware, so the rootStore becomes:
 
 ```typescript
 import logger from 'redux-logger';
@@ -559,7 +560,7 @@ const rootStore = configureStore({
 
 Since the code is running in simulators, how to use the Redux Devtools extension and view the Redux Logger?
 
-Open the debug menu in the simulator by entering `d` in the terminal that runs the start command. Then in the debug menu, choose “Debug with Chrome” for iOS and “Debug” for Android.
+Open the debug menu in the simulator by entering `d` in the terminal that runs the start command. Then in the debug menu, choose "Debug with Chrome" for iOS and "Debug" for Android.
 
 ![](/blog/images/2021-10-14/4QVoNHRjzW0agHGnxyWvpw.avif)
 _Debug Menu in iOS and Android_
@@ -587,7 +588,7 @@ npm install --save @react-navigation/native @react-navigation/stack react-native
 yarn add @react-navigation/native @react-navigation/stack react-native-reanimated react-native-gesture-handler react-native-screens @react-native-community/masked-view
 ```
 
-In the app’s package.json at `apps/daily-horoscope-app/package.json`, under dependencies, add the above packages:
+In the app's package.json at `apps/daily-horoscope-app/package.json`, under dependencies, add the above packages:
 
 ```json5
 {
@@ -728,7 +729,7 @@ export default App;
 
 In the `libs/ui/src/lib/zodiac-sign-list/zodiac-sign-list.tsx`, you need to trigger navigation when the list item got pressed.
 
-Below code uses [`useNavigation`](https://reactnavigation.org/docs/use-navigation/) hook from [React Navigation](https://reactnavigation.org/) library. When the list item got pressed, it is going to call `navigation.navigate(‘Horoscope Card’)` to navigate the `horoscope-card` component you created above.
+Below code uses [`useNavigation`](https://reactnavigation.org/docs/use-navigation/) hook from [React Navigation](https://reactnavigation.org/) library. When the list item got pressed, it is going to call `navigation.navigate('Horoscope Card')` to navigate the `horoscope-card` component you created above.
 
 [https://gist.github.com/xiongemi/c78c719e70aa4948b98e68033d7fe4a3](https://gist.github.com/xiongemi/c78c719e70aa4948b98e68033d7fe4a3)
 
@@ -800,7 +801,7 @@ nx generate lib services
 In the services folder, add the below files:
 
 - `aztro-horoscope-response.interface.ts` defines what the response object looks like. It has a transform function to transform response data to the app domain model.
-- `aztro.service.ts` calls the API to get the user’s horoscope based on the zodiac sign and day.
+- `aztro.service.ts` calls the API to get the user's horoscope based on the zodiac sign and day.
 
 ```typescript {% fileName="aztro-horoscope-response.interface.ts" %}
 import { AdhHoroscope, AdhZodiacSign } from '@aztro-daily-horoscope/models';
@@ -899,7 +900,7 @@ export interface HoroscopeState {
 
 - `loadingStatus` is the API request status from `aztro.service`.
 - `error` is the API request error from `aztro.service`.
-- `zodiacSignItem` is the user’s selected zodiac sign.
+- `zodiacSignItem` is the user's selected zodiac sign.
 - `day` is the parameter passed to `aztro.service`.
 - `horoscope` is the transformed response from `aztro.service.`
 
@@ -1255,7 +1256,7 @@ AppRegistry.runApplication('main', {
 });
 ```
 
-Copy your code from `daily-horoscope-app`’s app file to `daily-horoscope-web`’s app file and add styles for the icon font files:
+Copy your code from `daily-horoscope-app`'s app file to `daily-horoscope-web`'s app file and add styles for the icon font files:
 
 ```tsx {% fileName="app.tsx" %}
 import { rootStore } from '@aztro-daily-horoscope/store';

docs/blog/2021-12-17-mastering-the-project-boundaries-in-nx.md

@@ -4,11 +4,12 @@ slug: 'mastering-the-project-boundaries-in-nx'
 authors: ['Miroslav Jonaš']
 cover_image: '/blog/images/2021-12-17/PIUl1QGk7mOpSFdEwFQ8OA.png'
 tags: [nx]
+description: A comprehensive guide to organizing code in growing Nx repositories, exploring how to use module boundaries and ESLint rules to maintain clean architecture and prevent unintended cross-domain dependencies.
 ---
 
-As your repository grows, it becomes more challenging to organize and name the applications and libraries. This organization, when done right, feels intuitive and allows team members to easily find projects and understand how they work together. When done poorly, it results in a mess we eventually end up calling “the legacy software”. This article will show you different ways how you can prevent your repo from descending into chaos.
+As your repository grows, it becomes more challenging to organize and name the applications and libraries. This organization, when done right, feels intuitive and allows team members to easily find projects and understand how they work together. When done poorly, it results in a mess we eventually end up calling "the legacy software". This article will show you different ways how you can prevent your repo from descending into chaos.
 
-Our book [Enterprise Angular Monorepo Patterns](https://go.nx.dev/angular-enterprise-monorepo-patterns-new-book) presents an in-depth guide to assist you with naming and organization. If you still haven’t read this book, we warmly recommend you do. Don’t let the name fool you, though — the architecture guidelines explained in this book apply to any framework.
+Our book [Enterprise Angular Monorepo Patterns](https://go.nx.dev/angular-enterprise-monorepo-patterns-new-book) presents an in-depth guide to assist you with naming and organization. If you still haven't read this book, we warmly recommend you do. Don't let the name fool you, though — the architecture guidelines explained in this book apply to any framework.
 
 On large projects, you will most likely find multiple teams working on different parts of the solution. Those projects are usually split into logical domains, where each team focuses on a single domain. Each domain block can have a clear public API which other domains can use to consume the information.
 
@@ -47,13 +48,13 @@ When you generate the first project in your workspace using one of our generator
 }
 ```
 
-Let’s dissect what each of these properties does.
+Let's dissect what each of these properties does.
 
 The `allow` array acts as a whitelist listing the import definitions that should be omitted from further checks. You can read more about it in the **Overriding the overrides** section below.
 
 The `depConstraints` section is the one you will be spending most time fine-tuning. It represents an array of constraints, each consisting of `sourceTag` and `onlyDependOnLibsWithTags` properties. The default configuration has a wildcard `*` set as a value for both of them, meaning that any project can import (depend on) any other project.
 
-> Note, the wildcard only applies to libraries. Applications and E2E applications cannot be imported. It wouldn’t make any sense. If you want to combine applications, you should use the [micro-frontends](/recipes/angular/dynamic-module-federation-with-angular) approach with the module federation.
+> Note, the wildcard only applies to libraries. Applications and E2E applications cannot be imported. It wouldn't make any sense. If you want to combine applications, you should use the [micro-frontends](/recipes/angular/dynamic-module-federation-with-angular) approach with the module federation.
 
 The circular dependency chains such as `lib A -> lib B -> lib C -> lib A` are also not allowed. The self circular dependency (when lib imports from a named alias of itself), while not recommended, can be overridden by setting the flag `allowCircularSelfDependency` to true.
 
@@ -91,7 +92,7 @@ First, we will use the project configuration to annotate our projects with `tags
 
 - Tags used to live in `nx.json` but were in the recent version moved closer to the project, so you can locate them now in your `project.json` or `workspace.json`
 
-Let’s define the types of projects. We will use the following tags:
+Let's define the types of projects. We will use the following tags:
 
 - `type:app` for application
 - `type:feature` for feature library
@@ -147,12 +148,12 @@ Now, that we have marked all of our projects, we can continue to define the rule
 
 ## Adding a second dimension
 
-We said that a feature library can depend on any other feature library, but there is a small catch. Our two apps could be built with a different framework so mixing feature libraries would not be possible. To avoid any future impediments, we don’t want to allow a feature library used in `Store` to depend on the feature library from `Admin` and vice versa. Additionally, only our apps should be able to load the `Core` library.
+We said that a feature library can depend on any other feature library, but there is a small catch. Our two apps could be built with a different framework so mixing feature libraries would not be possible. To avoid any future impediments, we don't want to allow a feature library used in `Store` to depend on the feature library from `Admin` and vice versa. Additionally, only our apps should be able to load the `Core` library.
 
 ![](/blog/images/2021-12-17/mr_MbGgWVbBcfBhss0hNqA.avif)
 _Project graph with type tags and technology badges_
 
-Let’s add another dimension to allow such restrictions. We will define the necessary scope tags:
+Let's add another dimension to allow such restrictions. We will define the necessary scope tags:
 
 - `scope:store` for store app-related projects
 - `scope:admin` for admin app related projects
@@ -266,9 +267,9 @@ Using the wildcard `*` to match multiple projects e.g. `react*` we can save ours
 
 ## Restricting transitive dependencies
 
-Our solution doesn’t contain only internal projects but also depends on various external NPM packages. These external dependencies are explicitly declared in our `package.json`. Unfortunately, a package is rarely an island. They often consist of a tree of transitive dependencies branching out leading to thousands of packages being installed in your `node_modules` folder. Although we have control over what version or which direct dependency we install, we have no control over what versions of what packages this dependency depends on. The transitive dependencies are often the source of our app's vulnerabilities. We can also never guarantee those dependencies will be there. Just by simply running `npm install` parent may get updated to a patch or minor version that would wipe out one of the transitive dependencies or replace it with one with breaking changes.
+Our solution doesn't contain only internal projects but also depends on various external NPM packages. These external dependencies are explicitly declared in our `package.json`. Unfortunately, a package is rarely an island. They often consist of a tree of transitive dependencies branching out leading to thousands of packages being installed in your `node_modules` folder. Although we have control over what version or which direct dependency we install, we have no control over what versions of what packages this dependency depends on. The transitive dependencies are often the source of our app's vulnerabilities. We can also never guarantee those dependencies will be there. Just by simply running `npm install` parent may get updated to a patch or minor version that would wipe out one of the transitive dependencies or replace it with one with breaking changes.
 
-Therefore it’s wise not to allow developers to import transitive dependencies in their projects. Our ESLint plugin provides a simple flag to turn this restriction on.
+Therefore it's wise not to allow developers to import transitive dependencies in their projects. Our ESLint plugin provides a simple flag to turn this restriction on.
 
 ```json5 {% fileName=".eslintrc.json" %}
 {

docs/blog/2021-12-23-single-file-monorepo-config-custom-workspace-presets-improved-tailwind-support-and-more-in-nx-13.md

@@ -4,6 +4,7 @@ slug: 'single-file-monorepo-config-custom-workspace-presets-improved-tailwind-su
 authors: ['Brandon Roberts']
 cover_image: '/blog/images/2021-12-23/4u3Fw49H5U-sqgyBoGsqw.png'
 tags: [nx, release]
+description: Announcing Nx 13.4 with major improvements including single file monorepo configuration, custom workspace presets, enhanced Tailwind support for Angular, and dedicated TypeScript/JavaScript support with @nrwl/js, celebrating one million weekly downloads milestone.
 ---
 
 Nx is a smart, extensible build framework to help you architect, test, and build at any scale — integrating seamlessly with modern technologies and libraries while providing a robust CLI, computation caching, dependency management, and more.
@@ -25,13 +26,13 @@ With the latest release of Nx and add-nx-to-monorepo 2.0, there is only the **nx
 npx add-nx-to-monorepo
 ```
 
-> Victor Savkin demoed the flexibility of Nx by migrating Meta’s (Facebook) React repository: [video link](https://youtu.be/XLP2RAOwfLQ)
+> Victor Savkin demoed the flexibility of Nx by migrating Meta's (Facebook) React repository: [video link](https://youtu.be/XLP2RAOwfLQ)
 
 Learn more in our guide of [adding Nx to an existing workspace](/recipes/adopting-nx/adding-to-monorepo) and the config inside the [**nx.json**](/reference/project-configuration)**.**
 
 ## Custom Workspace Presets 🎨
 
-Nx provides many presets by default to support many different ecosystems. Nx for monorepos is like VSCode, where plugins allow you to extend the functionality of your monorepo to fit your ecosystem or platform of choice. To make it easier for scaffolding a pre-defined setup, we’ve introduced the ability to use custom presets when creating Nx workspaces with a provided npm package.
+Nx provides many presets by default to support many different ecosystems. Nx for monorepos is like VSCode, where plugins allow you to extend the functionality of your monorepo to fit your ecosystem or platform of choice. To make it easier for scaffolding a pre-defined setup, we've introduced the ability to use custom presets when creating Nx workspaces with a provided npm package.
 
 ```shell
 npx create-nx-workspace --preset=your-npm-package-name
@@ -47,7 +48,7 @@ This allows you to enhance the initial experience for new workspaces directly fo
 
 Nx has always shipped with great TypeScript support. In version 13.4 we improve it even further by releasing a brand new package: `@nrwl/js` .
 
-This is particularly useful if you have framework-agnostic TS/JS packages within an existing Nx workspace but also for those scenarios where you want to build and publish a TS/JS-based library to some package registry. The setup is very lightweight, but still provides all benefits you’d expect from an Nx-based setup such as Jest, ESLint, Prettier etc.
+This is particularly useful if you have framework-agnostic TS/JS packages within an existing Nx workspace but also for those scenarios where you want to build and publish a TS/JS-based library to some package registry. The setup is very lightweight, but still provides all benefits you'd expect from an Nx-based setup such as Jest, ESLint, Prettier etc.
 
 Read all the details on [our new TypeScript guide](/getting-started/intro) or check out the video walkthrough below.
 
@@ -58,7 +59,7 @@ Read all the details on [our new TypeScript guide](/getting-started/intro) or ch
 ![](/blog/images/2021-12-23/1yacozydc1muZ74G.avif)
 _Tailwind Logo_
 
-Tailwind is a utility-first CSS framework packed with classes that can be composed to build any design, directly in your markup. If you’ve used Tailwind with Angular applications previously, it's supported out of the box with Nx. We’re continually looking to improve the developer experience of using Tailwind in Angular applications and libraries. We already added support to the Angular plugin for Nx, and have added a new generator to configure Tailwind in **existing** apps and buildable/publishable libs, allowing you to set up and configure Tailwind without manual steps. The ability to configure new apps and libs is also supported, with support for Tailwind V2 and the latest V3 release.
+Tailwind is a utility-first CSS framework packed with classes that can be composed to build any design, directly in your markup. If you've used Tailwind with Angular applications previously, it's supported out of the box with Nx. We're continually looking to improve the developer experience of using Tailwind in Angular applications and libraries. We already added support to the Angular plugin for Nx, and have added a new generator to configure Tailwind in **existing** apps and buildable/publishable libs, allowing you to set up and configure Tailwind without manual steps. The ability to configure new apps and libs is also supported, with support for Tailwind V2 and the latest V3 release.
 
 ```shell
 nx g @nrwl/angular:app my-app --addTailwind