diff --git a/.eslintrc.base.json b/.eslintrc.base.json
new file mode 100644
index 0000000000..9ca2e830cb
--- /dev/null
+++ b/.eslintrc.base.json
@@ -0,0 +1,35 @@
+{
+  "root": true,
+  "ignorePatterns": ["**/*"],
+  "plugins": ["@nx"],
+  "overrides": [
+    {
+      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
+      "rules": {
+        "@nx/enforce-module-boundaries": [
+          "error",
+          {
+            "enforceBuildableLibDependency": true,
+            "allow": [],
+            "depConstraints": [
+              {
+                "sourceTag": "*",
+                "onlyDependOnLibsWithTags": ["*"]
+              }
+            ]
+          }
+        ]
+      }
+    },
+    {
+      "files": ["*.ts", "*.tsx"],
+      "extends": ["plugin:@nx/typescript"],
+      "rules": {}
+    },
+    {
+      "files": ["*.js", "*.jsx"],
+      "extends": ["plugin:@nx/javascript"],
+      "rules": {}
+    }
+  ]
+}
diff --git a/docs/blog/2023-08-15-qwikify-your-dev.md b/docs/blog/2023-08-15-qwikify-your-dev.md
new file mode 100644
index 0000000000..75a8578148
--- /dev/null
+++ b/docs/blog/2023-08-15-qwikify-your-dev.md
@@ -0,0 +1,609 @@
+---
+title: Qwikify your Development with Nx
+authors: ['Colum Ferry']
+cover_image: '/blog/images/2023-08-15/featured_img.png'
+tags: [nx, changelog, release]
+---
+
+In the ever-evolving web development landscape, efficiency and modularity have become paramount. This is where [Nx](https://nx.dev) and [Qwik](https://qwik.dev/) come into play.
+
+Qwik is a modern web framework that focuses on application performance by reducing the amount of JavaScript that needs to be shipped to the browser. You can learn more about how Qwik achieves this with [Resumability in their docs](https://qwik.dev/docs/concepts/resumable/).
+
+Nx is a powerful tool that helps you build extensible and maintainable codebases that scale as your application and team grows. Nx utilises computation cache and workspace analysis to ensure maximum efficiency and developer experience. You can [learn more about Nx here](/getting-started/why-nx).
+
+In this blog post, we’ll explore how to combine the strengths of Nx and Qwik to create a todo app. To do this, we’ll take advantage of an Nx Plugin that was created by the Qwikifiers team to maximise the integration between Qwik and Nx, called [`qwik-nx`](https://github.com/qwikifiers/qwik-nx).
+
+> You do not necessarily need to use an Nx Plugin for Qwik. Instead, you could use the [Qwik CLI](https://qwik.dev/docs/getting-started/#create-an-app-using-the-cli) to create your application and [add Nx later](/recipes/adopting-nx/adding-to-existing-project#installing-nx-on-a-non-monorepo-project).
+> In this blog post we use the `qwik-nx` plugin to leverage better DX provided by the generators offered by the Plugin.
+
+**Table of Contents**
+
+- [Creating the Workspace](#creating-the-workspace)
+- [Generate the App](#generate-the-app)
+- [Generate a new Route](#generate-a-new-route)
+- [Build a Basic UI](#build-a-basic-ui)
+- [Generate a Library](#generate-a-library)
+- [Add a Qwik Context](#add-a-qwik-context)
+- [Using the Context](#using-the-context)
+- [Adding a routeLoader$ to load data on Navigation](#adding-a-to-load-data-on-navigation)
+- [Handle the Form Action to add todos](#handle-the-form-action-to-add-todos)
+- [Improve the Architecture](#improve-the-architecture)
+- [Conclusion](#conclusion)
+- [Further Reading](#further-reading)
+
+You can learn more about this integration in the video below:
+
+{% youtube src="https://www.youtube.com/embed/SY22NaWHv0s?si=YrQp4qn7APU1f0U9" /%}
+
+## Creating the Workspace
+
+Let’s start by setting up our development environment. We’ll create an Nx workspace and integrate Qwik into it. Begin by generating an empty integrated workspace:
+
+```shell
+npx create-nx-workspace@latest qwik-todo-app
+```
+
+![](/blog/images/2023-08-15/bodyimg1.webp)
+
+> You can also use the `preset` created by the `qwik-nx` plugin by running `npx create-qwik-nx` or `npx -y create-nx-workspace@latest --preset=qwik-nx`. This will skip a few of the next steps by installing the appropriate dependencies and generating your Qwik app.
+>
+> The `create-qwik-nx` package is an example of creating an Install Package with Nx. You can learn more here: [https://nx.dev/extending-nx/recipes/create-install-package](/extending-nx/recipes/create-install-package)
+
+Next, navigate into the workspace and install the `qwik-nx` plugin.
+
+```shell
+npm install --save-dev qwik-nx
+```
+
+> You can view a compatibility matrix for which version of `qwik-nx` works with each version of `nx` [here](https://github.com/qwikifiers/qwik-nx#qwik-nx--nx-compatibility-chart).
+
+## Generate the App
+
+One of the benefits of using an Nx Plugin is that it comes with additional features such as automatic migrations, executors to act on your code and generators to scaffold code (_like CodeMods_).
+
+Now, let’s use the application generator provided by `qwik-nx` to scaffold the todo application:
+
+```shell
+nx g qwik-nx:app todo
+```
+
+This will generate the starter project that Qwik itself provides in your Nx Workspace. It will also install all the necessary packages to build a Qwik application.
+
+At this point, you can already run the `nx serve todo` and `nx build todo` commands to have a feel around of the application that was created.
+
+## Generate a new Route
+
+Qwik has another package called Qwik City that uses directory-based routing to handle navigation within your application. [Learn more about directory-based routing with Qwik City](https://qwik.dev/docs/qwikcity/).
+
+The `qwik-nx` plugin can help generate new routes within our application. Let’s use it to generate a route where we can store our todo logic.
+
+```shell
+nx g qwik-nx:route --name=todo --project=todo
+```
+
+After running this command, you’ll see a new directory and file created in your workspace:
+
+![Create apps/todo/src/routes/todo/index.tsx](/blog/images/2023-08-15/bodyimg2.webp)
+
+The newly created file should look like this:
+
+```js {% fileName="apps/todo/src/routes/todo/index.tsx" %}
+import { component$ } from '@builder.io/qwik';
+
+export default component$(() => {
+  return <div>This is the todo</div>;
+});
+```
+
+As you can see, it’s very simple, just a standard Qwik Component.
+
+If you run `nx serve todo` and navigate to `http://localhost:4200/todo` you can see that the route works and the component renders the content correctly.
+
+![Qwik displays the message "this is the todo"](/blog/images/2023-08-15/bodyimg3.webp)
+
+## Build a Basic UI
+
+We want to build a todo application, so let’s add some UI elements to make this look more like an actual todo application.
+
+Update `apps/todo/src/routes/todo/index.tsx` to match the following:
+
+```js {% fileName="apps/todo/src/routes/todo/index.tsx" %}
+import { component$ } from '@builder.io/qwik';
+import { Form } from '@builder.io/qwik-city';
+
+export default component$(() => {
+  return (
+    <div>
+      <h1>Todos</h1>
+      <div>
+        <label>
+          <input type="checkbox" /> {'My First Todo'}
+        </label>
+      </div>
+      <Form>
+        <input type="hidden" name="id" value={1} />
+        <input type="text" name="message" />
+        <button type="submit">Add</button>
+      </Form>
+    </div>
+  );
+});
+```
+
+You’ll see the page update and look like the following:
+
+![Qwik now the heading, a labeled checkbox, and a formfield to add a todo](/blog/images/2023-08-15/bodyimg4.webp)
+
+Awesome!
+
+However, you’ll notice that when you click `Add`, nothing happens! Let’s add some logic to store new todos.
+
+## Generate a Library
+
+Nx helps you organise your workspace in a modular fashion by creating workspace libraries that focus on specific functionality.
+
+Instead of organising your features into subfolders of your application, with Nx, you’ll extract them into workspace libraries (libraries that are not intended to be published, but still used by other libraries and applications in your repository). This helps to create a much stronger boundary between modules and features in your application as libraries have a public API (the `index.ts` file), allowing you to control exactly what can be accessed by consumers.
+
+> [Learn more about defining and ensuring project boundaries in the Nx docs.](/features/enforce-module-boundaries)
+>
+> By doing this, you start to build out a project graph for your workspace and your application. Defining your architecture in this manner also helps to reduce the areas in your application that each change affects.
+>
+> [Learn more about the Project Graph.](/concepts/mental-model#the-project-graph)
+
+Using this feature of Nx, we can organise the state management of our todo application into its own library, separating the logic from the application itself.
+
+Let’s generate a new library with the help of `qwik-nx`.
+
+```shell
+nx g qwik-nx:lib data-access
+```
+
+![The list of files generated.](/blog/images/2023-08-15/bodyimg5.webp)
+
+We do not need some of the files that were automatically generated so we can delete them:
+
+```
+libs/data-access/src/lib/data-access.tsx
+libs/data-access/src/lib/data-access.css
+libs/data-access/src/lib/data-access.spec.tsx
+```
+
+## Add a Qwik Context
+
+Qwik uses [Contexts](https://qwik.dev/docs/components/context/) to help store state across both the server-side and client-side and across routes within the application.
+
+We’ll use a Context to store the todos in the application, but first, let’s create a file to store the TS Interfaces we’ll use in our application.
+
+Create `libs/data-access/src/lib/api.ts` and add the following:
+
+```ts {% fileName="libs/data-access/src/lib/api.ts" %}
+export interface Todo {
+  id: number;
+  message: string;
+}
+```
+
+Next, let’s create a new file `libs/data-access/src/lib/todo.context.tsx` and add the following content:
+
+```tsx {% fileName="libs/data-access/src/lib/todo.context.tsx" %}
+import {
+  component$,
+  createContextId,
+  Slot,
+  useContextProvider,
+  useStore,
+} from '@builder.io/qwik';
+import { Todo } from './api';
+
+interface TodoStore {
+  todos: Todo[];
+  lastId: number;
+}
+
+export const TodoContext = createContextId<TodoStore>('todo.context');
+export const TodoContextProvider = component$(() => {
+  const todoStore = useStore<TodoStore>({
+    todos: [],
+    lastId: 0,
+  });
+  useContextProvider(TodoContext, todoStore);
+  return <Slot />;
+});
+```
+
+This will create our Context and set up a Store within our application to store the todos. Qwik takes advantage of signals to update state and inform the framework of which components need to be re-rendered when the state changes.
+
+> [Learn more about how Qwik uses Signals.](https://qwik.dev/docs/components/state/)
+
+Finally, let’s update the public entry point to the library to expose our Context and Interface.
+
+## Using the Context
+
+Let’s update the root page to add our Context Provider. Open `apps/todo/src/root.tsx` and add `TodoContextProvider` after `QwikCityProvider` in the component tree. Your file should look like the following:
+
+```tsx {% fileName="apps/todo/src/root.tsx" %}
+import { component$, useStyles$ } from '@builder.io/qwik';
+import {
+  QwikCityProvider,
+  RouterOutlet,
+  ServiceWorkerRegister,
+} from '@builder.io/qwik-city';
+import { RouterHead } from './components/router-head/router-head';
+import globalStyles from './global.css?inline';
+import { TodoContextProvider } from '@qwik-todo-app/data-access';
+
+export default component$(() => {
+  /**
+   * The root of a QwikCity site always start with the <QwikCityProvider> component,
+   * immediately followed by the document's <head> and <body>.
+   *
+   * Don't remove the `<head>` and `<body>` elements.
+   */
+  useStyles$(globalStyles);
+  return (
+    <QwikCityProvider>
+      <TodoContextProvider>
+        <head>
+          <meta charSet="utf-8" />
+          <link rel="manifest" href="/manifest.json" />
+          <RouterHead />
+        </head>
+        <body lang="en">
+          <RouterOutlet />
+          <ServiceWorkerRegister />
+        </body>
+      </TodoContextProvider>
+    </QwikCityProvider>
+  );
+});
+```
+
+Update `libs/data-access/src/index.ts` to match the following:
+
+```ts {% fileName="libs/data-access/src/index.ts" %}
+export * from './lib/todo.context';
+export * from './lib/api';
+```
+
+Now that our Context is in place, let’s use it in our todo route to manage our todos.
+
+Update `apps/todo/src/routes/todo/index.tsx` to match the following:
+
+```tsx {% fileName="apps/todo/src/routes/todo/index.tsx" %}
+import { component$ } from '@builder.io/qwik';
+import { Form } from '@builder.io/qwik-city';
+import { TodoContext } from '@qwik-todo-app/data-access';
+
+export default component$(() => {
+  const todoStore = useContext(TodoContext);
+  return (
+    <div>
+      <h1>Todos</h1>
+      {todoStore.todos.map((t) => (
+        <div key={`todo-${t.id}`}>
+          <label>
+            <input type="checkbox" /> {t.message}
+          </label>
+        </div>
+      ))}
+      <Form>
+        <input type="hidden" name="id" value={1} />
+        <input type="text" name="message" />
+        <button type="submit">Add</button>
+      </Form>
+    </div>
+  );
+});
+```
+
+Our store has no todos in it when the application starts up, so if you serve the application you will no longer see any todos listed. Let’s fix that!
+
+## Adding a `routeLoader$` to load data on Navigation
+
+Qwik allows you to fetch data when a route is navigated to, allowing you to fetch data before the page is rendered. The data will be fetched on the server before the component is rendered and downloaded to the client.
+
+> [Learn more about routeLoader$.](https://qwik.dev/docs/route-loader/)
+
+It does this by providing a function called `routeLoader$`. We’ll use this function to preload our store with some todos that will theoretically exist in a database.
+
+For this blog post, we’ll create an in-memory db to store some initial todos.
+
+We’ll start by updating our `libs/data-access/src/lib/api.ts` to add our in-memory DB.
+
+```ts {% fileName="libs/data-access/src/lib/api.ts" %}
+export interface Todo {
+  id: number;
+  message: string;
+}
+
+interface DB {
+  store: Record<string, any[]>;
+  get: (storeName: string) => any[];
+  set: (storeName: string, value: any[]) => boolean;
+  add: (storeName: string, value: any) => boolean;
+}
+export const db: DB = {
+  store: { todos: [] },
+  get(storeName) {
+    return db.store[storeName];
+  },
+  set(storeName, value) {
+    try {
+      db.store[storeName] = value;
+      return true;
+    } catch (e) {
+      return false;
+    }
+  },
+  add(storeName, value) {
+    try {
+      db.store[storeName].push(value);
+      return true;
+    } catch (e) {
+      return false;
+    }
+  },
+};
+```
+
+Now that we have this, let’s use it in our `/todo` route to load some data when the user navigates to `/todo`.
+
+Update `apps/todo/src/routes/todo/index.tsx` to match the following:
+
+```tsx {% fileName="apps/todo/src/routes/todo/index.tsx" %}
+import { component$ } from '@builder.io/qwik';
+import { Form, routeLoader$ } from '@builder.io/qwik-city';
+import { TodoContext, db } from '@qwik-todo-app/data-access';
+
+export const useGetTodos = routeLoader$(() => {
+  // A network request or db connection could be made here to fetch persisted todos
+  // For illustrative purposes, we're going to seed a rudimentary in-memory DB if it hasn't been already
+  // Then return the value from it
+  if (db.get('todos')?.length === 0) {
+    db.set('todos', [
+      {
+        id: 1,
+        message: 'First todo',
+      },
+    ]);
+  }
+  const todos: Todo[] = db.get('todos');
+  const lastId = [...todos].sort((a, b) => b.id - a.id)[0].id;
+  return { todos, lastId };
+});
+export default component$(() => {
+  const todoStore = useContext(TodoContext);
+  const persistedTodos = useGetTodos();
+  useTask$(({ track }) => {
+    track(() => persistedTodos.value);
+    if (persistedTodos.value) {
+      todoStore.todos = persistedTodos.value.todos;
+      todoStore.lastId =
+        todoStore.lastId > persistedTodos.value.lastId
+          ? todoStore.lastId
+          : persistedTodos.value.lastId;
+    }
+  });
+  return (
+    <div>
+      <h1>Todos</h1>
+      {todoStore.todos.map((t) => (
+        <div key={`todo-${t.id}`}>
+          <label>
+            <input type="checkbox" /> {t.message}
+          </label>
+        </div>
+      ))}
+      <Form>
+        <input type="hidden" name="id" value={1} />
+        <input type="text" name="message" />
+        <button type="submit">Add</button>
+      </Form>
+    </div>
+  );
+});
+```
+
+When you serve the application, you’ll see the first todo is fetched and rendered correctly!
+
+## Handle the Form Action to add todos
+
+Qwik also allows you to handle form actions on the server using the `routeAction$` API. Let’s create the logic to add new todos to the store.
+
+> [Learn more about `routeAction$`](https://qwik.dev/docs/action/)
+
+Update `apps/todo/src/routes/todo/index.tsx`:
+
+```tsx {% fileName="apps/todo/src/routes/todo/index.tsx" %}
+import { component$ } from '@builder.io/qwik';
+import { Form, routeLoader$ } from '@builder.io/qwik-city';
+import { TodoContext, db } from '@qwik-todo-app/data-access';
+
+export const useGetTodos = routeLoader$(() => {
+  // A network request or db connection could be made here to fetch persisted todos
+  // For illustrative purposes, we're going to seed a rudimentary in-memory DB if it hasn't been already
+  // Then return the value from it
+  if (db.get('todos')?.length === 0) {
+    db.set('todos', [
+      {
+        id: 1,
+        message: 'First todo',
+      },
+    ]);
+  }
+  const todos: Todo[] = db.get('todos');
+  const lastId = [...todos].sort((a, b) => b.id - a.id)[0].id;
+  return { todos, lastId };
+});
+export const useAddTodo = routeAction$(
+  (todo: { id: string; message: string }) => {
+    const success = db.add('todos', {
+      id: parseInt(todo.id),
+      message: todo.message,
+    });
+    return { success };
+  },
+  zod$({ id: z.string(), message: z.string() })
+);
+export default component$(() => {
+  const todoStore = useContext(TodoContext);
+  const persistedTodos = useGetTodos();
+  const addTodoAction = useAddTodo();
+
+  useTask$(({ track }) => {
+    track(() => persistedTodos.value);
+    if (persistedTodos.value) {
+      todoStore.todos = persistedTodos.value.todos;
+      todoStore.lastId =
+        todoStore.lastId > persistedTodos.value.lastId
+          ? todoStore.lastId
+          : persistedTodos.value.lastId;
+    }
+  });
+  return (
+    <div>
+      <h1>Todos</h1>
+      {todoStore.todos.map((t) => (
+        <div key={`todo-${t.id}`}>
+          <label>
+            <input type="checkbox" /> {t.message}
+          </label>
+        </div>
+      ))}
+      <Form action={addTodoAction}>
+        <input type="hidden" name="id" value={todoStore.lastId + 1} />
+        <input type="text" name="message" />
+        <button type="submit">Add</button>
+      </Form>
+      {addTodoAction.value?.success && <p>Todo added!</p>}
+    </div>
+  );
+});
+```
+
+Awesome! We can now add todos to our application!
+
+However, you might have noticed that our file is starting to get very long. Not only that there’s a lot of logic in the route file itself. Let’s use Nx to separate the logic into the library we created earlier to keep logic collocated.
+
+## Improve the Architecture
+
+To separate the logic, create a new file `libs/data-access/src/lib/todos.ts` and move the logic for loading and adding todos into their own functions:
+
+```ts {% fileName="libs/data-access/src/lib/todos.ts" %}
+import { db, Todo } from './api';
+
+export function getTodos() {
+  // A network request or db connection could be made here to fetch persisted todos
+  // For illustrative purposes, we're going to seed a rudimentary in-memory DB if it hasn't been already
+  // Then return the value from it
+  if (db.get('todos')?.length === 0) {
+    db.set('todos', [
+      {
+        id: 1,
+        message: 'First todo',
+      },
+    ]);
+  }
+  const todos: Todo[] = db.get('todos');
+  const lastId = [...todos].sort((a, b) => b.id - a.id)[0].id;
+  return { todos, lastId };
+}
+export function addTodo(todo: { id: string; message: string }) {
+  const success = db.add('todos', {
+    id: parseInt(todo.id),
+    message: todo.message,
+  });
+  return { success };
+}
+```
+
+Next, update `libs/data-access/src/index.ts`
+
+```ts {% fileName="libs/data-access/src/index.ts" %}
+export * from './lib/todo.context';
+export * from './lib/api';
+export * from './lib/todo';
+```
+
+Finally, let’s update `apps/todo/src/routes/todo/index.tsx` to use our newly created functions:
+
+```tsx {% fileName="apps/todo/src/routes/todo/index.tsx" %}
+import { component$, useContext, useTask$ } from '@builder.io/qwik';
+import {
+  Form,
+  routeAction$,
+  routeLoader$,
+  z,
+  zod$,
+} from '@builder.io/qwik-city';
+import { addTodo, getTodos, TodoContext } from '@acme/data-access';
+
+export const useGetTodos = routeLoader$(() => getTodos());
+export const useAddTodo = routeAction$(
+  (todo) => addTodo(todo),
+  zod$({ id: z.string(), message: z.string() })
+);
+export default component$(() => {
+  const todoStore = useContext(TodoContext);
+  const persistedTodos = useGetTodos();
+  const addTodoAction = useAddTodo();
+  useTask$(({ track }) => {
+    track(() => persistedTodos.value);
+    if (persistedTodos.value) {
+      todoStore.todos = persistedTodos.value.todos;
+      todoStore.lastId =
+        todoStore.lastId > persistedTodos.value.lastId
+          ? todoStore.lastId
+          : persistedTodos.value.lastId;
+    }
+  });
+  return (
+    <div>
+      <h1>Todos</h1>
+      {todoStore.todos.map((t) => (
+        <div key={`todo-${t.id}`}>
+          <label>
+            <input type="checkbox" /> {t.message}
+          </label>
+        </div>
+      ))}
+      <Form action={addTodoAction}>
+        <input type="hidden" name="id" value={todoStore.lastId + 1} />
+        <input type="text" name="message" />
+        <button type="submit">Add</button>
+      </Form>
+      {addTodoAction.value?.success && <p>Todo added!</p>}
+    </div>
+  );
+});
+```
+
+If you run `nx serve todo` again, you’ll notice that our refactor will not have changed anything for the user, but it has made the codebase more manageable!
+
+Now, if we need to update the logic for loading or adding todos, we only need to retest the library, and not the full application, improving our CI times!
+
+![](/blog/images/2023-08-15/bodyimg6.webp)
+
+## Conclusion
+
+The collaboration between Nx and Qwik has led us to create a todo app that showcases efficient development practices and modular design. By centralizing route logic in a library, we’ve not only demonstrated the capabilities of Nx and Qwik but also highlighted how this approach can significantly improve cache and CI times.
+
+This journey through Qwik and Nx demonstrates how thoughtful architecture and the right tools can significantly enhance your development experience. So go ahead, Qwikify your development and build amazing web applications with ease!
+
+## Further Reading
+
+- [Qwik](https://qwik.dev/)
+- [qwik-nx](https://github.com/qwikifiers/qwik-nx)
+- [Enforce Module Boundaries](/features/enforce-module-boundaries)
+- [Nx Core Concepts](/concepts)
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2023-10-20-nx-17-release.md b/docs/blog/2023-10-20-nx-17-release.md
new file mode 100644
index 0000000000..03f60ec320
--- /dev/null
+++ b/docs/blog/2023-10-20-nx-17-release.md
@@ -0,0 +1,282 @@
+---
+title: 'Nx 17 has Landed'
+authors: ['Juri Strumpflohner', 'Zack DeRose']
+cover_image: '/blog/images/2023-10-20/featured_img.png'
+tags: [nx, design]
+---
+
+{% youtube src="https://www.youtube.com/embed/1Z0iA9K1o8M?si=9XxIboXSZ5yxFpIt" /%}
+
+We’re excited to announce the release of Nx version 17!
+
+This article will cover the main things you need to know to get the most out of Nx 17!
+
+Here’s a Table of Contents so you can skip straight to the updates you care about the most:
+
+- [It's a Vue-tiful Day for Nx](#its-a-vuetiful-day-for-nx)
+- [Enhancements to Module Federation Support](#enhancements-to-module-federation-support)
+- [More Consistent Generator Paths](#more-consistent-generator-paths)
+- [The NEW Nx AI Chatbot](#the-new-nx-ai-chatbot)
+- [More Seamless Integration With Nx Cloud](#more-seamless-integration-with-nx-cloud)
+- [`nx.json` Simplification](#simplification)
+- [Nx Repo Begins Dog-Fooding Nx Workflows](#nx-repo-dogfooding-nx-workflows)
+- [Task Graphing Improvements](#task-graphing-improvements)
+- [`@nx/linter` Renames to `@nx/eslint`](#renamed-to)
+- [New Experimental Feature: Nx Release](#new-experimental-feature-nx-release)
+- [Experimental: Nx Project Inference API v2](#experimental-nx-project-inference-api-v2)
+- [20k Github Stars!!](#20k-github-stars)
+
+## It’s a Vue-tiful Day for Nx!
+
+Ever since we added Vite as a first-class citizen to Nx workspaces (see `@nx/vite`), we started falling in love with the Vue community. The only logical next step: Nx now provides a brand new Vue plugin that is being maintained by the Nx team! (And we're already working on a [Nuxt](https://nuxt.com/) plugin 🤫)
+
+The first place you might notice this new support is in the `create-nx-workspace` script:
+
+![](/blog/images/2023-10-20/bodyimg1.webp)
+
+This option will create a new Nx workspace with a fresh Vue application, all set up and ready to develop! To add new Vue projects to your existing Nx workspaces, add our new @nx/vue package as a dev dependency to your workspace, e.g.:
+
+```shell
+> npm add -D @nx/vue
+```
+
+And you’ll have access to Nx generators so that you can generate Vue applications, libraries, components, and more in your workspace:
+
+![](/blog/images/2023-10-20/bodyimg2.gif)
+
+We’re very excited for this support to land, and we’re eager to get it into our user’s hands and see what Nx can do to help Vue developers so we can continue to refine our support and make Vue with Nx an excellent developer experience.
+
+If you’re eager to learn more, make sure to check out our new [Vue standalone tutorial](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial).
+
+## Enhancements to Module Federation Support
+
+Nx already had great support for Module Federation — Nx 17 improves on this support:
+
+### NEW: Typesafe Config
+
+Projects created with Nx’s generators for module federation will now be created with a `module-federation.config.ts` file (as opposed to a `.js` file). A new `ModuleFederationConfig` interface is also exported from the `@nx/webpack` plugin.
+
+### Better Typesafety Across Modules
+
+Nx 17 improves type-safety across modules, so proper type-safety is currently supported across dynamic imports.
+
+![](/blog/images/2023-10-20/bodyimg3.gif)
+
+### NEW GENERATOR: Federate ANYTHING.
+
+The `@nx/react` and `@nx/angular` now include a `federate-module` generator. This will allow you to create a federated module from any Nx project.
+
+To run this generator, use the command:
+
+```shell
+> nx g federate-module <module name> --path=<path to module to be exposed> --remote=<name of remote exposing module>
+```
+
+This will add a new module to the `exposes` map in the specified `remote` application, such that it can be consumed by a `host` application.
+
+### Managing Module Versions
+
+Nx now supports targeted versioning for federated modules.
+
+To create versions for a given project, you can use the `version` property of that project's `package.json` file and then build that project to create the version locally.
+
+Then, when consuming this library, you can use the `shared` method of the `ModuleFederationConfig`:
+
+```ts
+import { ModuleFederationConfig } from '@nx/webpack';
+
+const config: ModuleFederationConfig = {
+  name: 'my-remote',
+  exposes: {
+    './Module': 'apps/my-remote/src/app/remote-entry/entry.module.ts',
+  },
+  remotes: ['federated-is-odd'],
+  shared: (libName, configuration) => {
+    if (libName === 'is-odd') {
+      return {
+        singleton: true,
+        strictVersion: true,
+        requiredVersion: '0.0.1',
+      };
+    }
+    return configuration;
+  },
+};
+
+export default config;
+```
+
+This config will ensure that version `0.0.1` of the `is-odd` is used.
+
+## More Consistent Generator Paths
+
+Similar to the [adjustments we made in 16.8](https://www.youtube.com/watch?v=bw8pRh0iC4A&t=14s) for most of our project-creating generators, v17 brings updates to how component generators work. These updates aim to give you more control over the name and file location of your components.
+
+Towards this end, we’ve added a new `--nameAndDirectoryFormat` option that you can set to either `as-provided` or `derived`.
+
+When set to `as-provided`, the generator will use the `name` option for the name of your component and the `directory` option to determine where on your file system to add the component. `as-provided` will be used by default if none is specified.
+
+When set to `derived`, the generator will try to determine where to create your component based on the `project` option - which will mainly operate how component generators do now.
+
+In addition, component generators now follow any given casing for component files. For example, let’s say we have an integrated monorepo with a react application called “my-app” and want to add a “Home” component. With Nx 17, you can run the command:
+
+```shell
+> nx g component Home --directory=apps/my-app/src/app
+```
+
+And a `Home.tsx` file will be added in the `apps/my-app/src/app` directory.
+
+You can now also build your directory path right into the generator command. For example, the same “Home” component would be created via:
+
+```shell
+> nx g component apps/my-app/src/app/Home
+```
+
+Finally, generators will now factory in your current working directory, so you can also create this “Home” component via:
+
+```shell
+> cd apps/my-app/src/app
+> nx g component Home
+```
+
+## The NEW Nx AI ChatBot
+
+We’ve added a new AI ChatBot to our docs site. You can access it now at [https://nx.dev/ai-chat](https://nx.dev/ai-chat).
+
+![](/blog/images/2023-10-20/bodyimg4.gif)
+
+This feature is still in beta, so please use the thumbs up/thumbs down buttons to provide feedback on whether the chatbot is accurate and helpful!
+
+## More Seamless Integration With Nx Cloud
+
+After running the `nx migrate` command to upgrade to Nx 17 and using Nx Cloud, you may have observed the removal of `nx-cloud` from your dev dependencies. Don't worry - Nx Cloud is not only still around but thriving. Instead of having a standalone package, we've integrated the Nx Cloud communication layer directly into the `nx` package. This ensures a seamless connection whenever you opt in and eliminates potential version misalignment concerns with our API endpoint.
+
+## `nx.json` Simplification
+
+Our Nx Cloud updates come alongside configuration changes in your `nx.json` file and project configuration.
+
+Specifically, we’ve added an optional `nxCloudAccessToken` to the `nx.json` file - as long as a token is provided here, we'll make sure that you take advantage of the currently deployed version of Nx Cloud when running commands with Nx.
+
+We’ve also removed the need to specify `cacheableOperations` at the task-runner level. From now on, every `target` configured in your `project.json` can be defined as cacheable using the `cache` property.
+
+```json {% fileName="nx.json" %}
+{
+    "targetDefaults": {
+        "build": {
+            "cache": true,
+            ...
+        }
+    }
+}
+```
+
+If you use the `nx migrate` command, all updates will be handled for you using the `targetDefaults` in your `nx.json` file. [More in the docs.](https://nx.dev/features/cache-task-results)
+
+We’ve been working hard at reducing and simplifying all the configuration required for your Nx workspaces. Checkout our latest guide on how to [Reduce Repetitive Configuration](https://nx.dev/recipes/running-tasks/reduce-repetitive-configuration) for more, and stay tuned as we’ve got new efforts underway to make this simplification even more appealing!
+
+## Nx Repo Dog-Fooding Nx Workflows
+
+At Nx Conf in New York City, we unveiled the next big step for Nx: **Nx Workflows**.
+
+If you missed it, Simon Critchley walks you through in his [Nx Conf](https://dev.to/nx/nx-conf-2023-recap-53ep) talk:
+
+{% youtube src="https://www.youtube.com/embed/JG1FWfZFByM?si=7_NzxJP8nA7RbFhl" /%}
+
+Put simply, Nx Workflows represents Nx entering the CI provider arena, where Nx can now provide you with Cloud Computation to run your CI tasks. This creates the foundation for a whole new class of Nx Cloud features that we’re excited to work on in the coming cycles.
+
+The Nx repo itself is now “dog-fooding” this latest feature (dog-fooding refers to using our tool in our own projects, or “eating our own dog food”), and you can see how it’s going now on our [public Nx Cloud workspace](https://staging.nx.app/orgs/62d013d4d26f260059f7765e/workspaces/62d013ea0852fe0a2df74438/overview).
+
+![](/blog/images/2023-10-20/bodyimg5.webp)
+
+Nx Workflows are still in the experimental phase. We’re running pilots with our enterprise clients and are excited to open this up for everyone soon!
+
+## Task Graphing Improvements
+
+Task Caching in Nx is based on a set of “input” files calculated for a given task. You can specify specific files or patterns of files in your project.json for a particular task or in the `targetDefaults` of your `nx.json` to set the default file sets for your inputs.
+
+There have been some difficulties in determining precisely which files were included and which weren’t for a given task. This is where our latest update to the task graph comes in:
+
+![](/blog/images/2023-10-20/bodyimg6.webp)
+
+You can open this graph using the command:
+
+```shell
+> nx graph
+```
+
+And then selecting “Task” from the “Project”/”Task” graph dropdown in the top left. Clicking on a specific task now allows you to see a comprehensive list of all files that were factored in as inputs for this task:
+
+![](/blog/images/2023-10-20/bodyimg7.webp)
+
+## `@nx/linter` Renamed to `@nx/eslint`
+
+After running `nx migrate`, you may have noticed that the `@nx/linter` plugin was removed and replaced with `@nx/eslint`.
+
+In Nx 17, we removed any remaining traces of `tslint` from our linter package, so this is mainly a simple rename to more accurately describe the package (and to remove any confusion that this package is intended to support linting for other languages/platforms).
+
+## New Experimental Feature: Nx Release
+
+`nx release` is a new top level command on the Nx CLI which is designed to help you with versioning, changelog generation, and publishing of your projects:
+
+- `nx release version` - Determine and apply version updates to projects and their dependents
+- `nx release changelog` - Generate CHANGELOG.md files and optional Github releases based on git commits
+- `nx release publish` - Take the freshly versioned projects and publish them to a remote registry
+
+`nx release` is still experiment and therefore subject to change, but the Nx repo itself is now using these commands to version itself, as well as generate changelogs, [Github releases](https://github.com/nrwl/nx/releases/tag/17.0.3), and publish our packages to npm.
+
+As we solidify this command, we intend to bring robust support for various versioning and publishing strategies, as well as built-in support for publishing packages or modules to a variety of languages, registries, and platforms.
+
+For more [checkout our API docs](https://nx.dev/nx-api/nx/documents/release), and be sure to catch James Henry’s announcement of this new command at [Nx Conf](https://dev.to/nx/nx-conf-2023-recap-53ep):
+
+{% youtube src="https://www.youtube.com/embed/p5qW5-2nKqI?si=FzpGMJwPVINc1hgL" /%}
+
+## Experimental: Nx Project Inference API v2
+
+At Nx, we’re OBSESSED with building a better, more robust experience for our developers. Towards this end, we’re now in [v2 of our Project Inference API](https://nx.dev/extending-nx/recipes/project-graph-plugins).
+
+This API is a way of extending the Nx project graph, which can be particularly helpful for extending Nx to support other languages, allowing Nx to determine where to find and draw boundaries around projects in your workspace. A great example is our very own [Vue plugin](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial).
+
+Interestingly, v2 includes support for dynamic targets as well. This opens up exciting new doors to reducing configuration, and we hope to expand on this to better support our first-party plugins in the near future.
+
+For most developers, the main thing you need to know is that plugins may now add additional targets that you won’t see in your `project.json` file. To see your actual project configuration, you can now use the command:
+
+```shell
+> nx show project <project_name>
+```
+
+For plugin authors, check out the [v2 documentation](https://nx.dev/extending-nx/recipes/project-graph-plugins) to see how you can take advantage of the new API to deliver a better experience to your users.
+
+## 20k Github Stars!!
+
+Nx is SOOO CLOSE to 20,000 stars on github! If Nx has been helpful to you, [please help us get there](https://github.com/nrwl/nx)!
+
+![](/blog/images/2023-10-20/bodyimg8.webp)
+
+## How to Update Nx
+
+Nx is known to [help you automatically migrate](https://nx.dev/features/automate-updating-dependencies) to the new version (including potentially breaking changes). To update simply run:
+
+```shell
+> npx nx migrate latest
+```
+
+This will update your Nx workspace dependencies, configuration and code to the latest version. After updating your dependencies, run any necessary migrations:
+
+```shell
+> npx nx migrate --run-migrations
+```
+
+## Wrapping up
+
+That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to our [YouTube channel](https://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
+
+---
+
+## Learn more
+
+- [Nx Docs](https://nx.dev/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2023-12-20-nx-17-2-release.md b/docs/blog/2023-12-20-nx-17-2-release.md
new file mode 100644
index 0000000000..615ecc8f5e
--- /dev/null
+++ b/docs/blog/2023-12-20-nx-17-2-release.md
@@ -0,0 +1,214 @@
+---
+title: Nx 17.2 Update
+authors: [Zack DeRose]
+cover_image: '/blog/images/2023-12-20/featured_img.png'
+tags: [nx, changelog, release]
+---
+
+It’s been a bit since we launched [Nx 17](/blog/2023-10-20-nx-17-release)! In this article, we’ll go over some of the new developments and improvements that have landed in Nx 17.2:
+
+- [Nx Closes In On 4 Million Weekly NPM Downloads!!](#nx-closes-in-on-4-million-weekly-npm-downloads)
+- [New Simplified Project Configuration On the Way](#new-simplified-project-configuration-on-the-way)
+- [Rust for Speed, Typescript for Extensibility](#rust-for-speed-typescript-for-extensibility)
+- [Module Federation Updates](#module-federation-updates)
+- [Nx Release Updates](#nx-release-updates)
+- [Angular 17 (AND NgRx 17) Support](#angular-17-and-ngrx-17-support)
+- [Smart Monorepos — Fast CI](#smart-monorepos-fast-ci)
+- [New Canary Releases](#new-canary-releases)
+- [Upcoming Release Livestream](#upcoming-release-livestream)
+- [Automatically Update Nx](#automatically-update-nx)
+
+## Nx Closes In On 4 Million Weekly NPM Downloads!!
+
+2023 has been a great year for Nx! We worked with a lot of the teams out there building fantastic open source tools. And you can see the results: we made [Vite](https://vitejs.dev/) a first class citizen in many of our Nx plugins, we added support for [Rspack](https://www.youtube.com/watch?v=jGTE7xAcg24), streamlined our Node experience by adding an Nx team maintained [Fastify plugin](https://www.youtube.com/watch?si=P5MPIiD_mxTpQStY&v=LHLW0b4fr2w&feature=youtu.be), support for Storybook interaction testing, welcomed Playwright to the family and much more, continuing our missing to push developer productivity to the limits!
+
+And our downloads on NPM keep confirming this. We are about to cross 4 million downloads per week.
+
+![](/blog/images/2023-12-20/bodyimg1.webp)
+
+If this made you curious, keep an eye on [our blog](/blog) or [X/Twitter](https://twitter.com/nxdevtools) as we’re going to release a 2023 year recap blog post next week.
+
+## New Simplified Project Configuration On the Way
+
+Adoption is crucial, and simplicity is the driver for adoption. Last year we heavily optimized how you can use Nx in an existing project. Just drop the `nx` package (or run `nx init`) and that's it. Nx understands your workspace and efficiently runs your `package.json` scripts.
+
+Using Nx at that level is definitely useful as you get intelligent parallelization, task pipelines and caching. But it is just the tip of the iceberg of what Nx is actually capable of. Nx plugins provide much more, especially in terms of DX and developer productivity by taking away some of the burden of configuring your monorepo tooling. But many devs new to Nx found it harder to get started with them initially and incrementally migrating to Nx plugins wasn’t as straightforward as we’d wanted it to be.
+
+This is something that’s gonna change drastically in 2024. And we’ve layed the first cornerstone for that. But it is behind a feature flag still as we’re streamlining the last bits. The goal?
+
+- Going almost configuration-less (good defaults, you customize when you need to)
+- Allowing easy drop-in of Nx plugins into existing workspaces (provides immediate productivity gains, but stays out of your way)
+
+This opens up a series of possibilities which we’re already super excited about. You’ll hear more about this in the new year ;)
+
+## Rust for Speed, Typescript for Extensibility
+
+At Nx, we’ve heavily embraced Typescript from the beginning, and we’ve been very happy with that decision.
+
+If you’ve been paying attention to previous release announcements though, you’ve probably noticed that we’ve been moving more and more of the computationally intensive and performance critical pieces of the core of Nx from Typescript to Rust.
+
+That trend continues in Nx 17.2 with Nx [using Rust for its task hashing by default](https://github.com/nrwl/nx/pull/19617). There’s no adjustments needed for this change, and Nx will continue to behave the same way, just faster!
+
+{% tweet url="https://twitter.com/victorsavkin/status/1724464283227234420" /%}
+
+## Module Federation Updates
+
+Module Federation has been a particularly hot topic lately, and 17.2 is coming in with some great enhancements to Nx’s already best-in-class support for Module Federation!
+
+To start, we’ve greatly reduced the CPU and memory used for standing up your Module Federation “web” locally. These enhancements should be great news to larger workspaces using a Module Federation approach, where there were heavy CPU and memory costs to serving your entire federation locally.
+
+We accomplished these improvements by batching any applications that are not being watched for changes (listed with the `--devRemotes` option) to a single server, rather than a unique server for each application. We also parallelized the builds of these static applications when you start up your serve! You can now use the `--parallel={number}` option to specify how many builds you want going at any given time.
+
+In addition to performance improvements, we’ve brought the concept of dynamic federation to our React module federation support. Dynamic federation allows a host application to dynamically load remotes via the manifest file.
+
+You can generate your react module federation workspace now to use dyanmic federation via the `--dynamic` flag:
+
+```shell
+nx generate @nx/react:host acme --remotes=nx --dynamic
+```
+
+Or you can use the utility itself by importing from `@nx/react/mf`:
+
+```ts
+import { loadRemoteModule } from '@nx/react/mf';
+```
+
+Lastly, we have an [example repo](https://github.com/jaysoo/nx-react-vite-module-federation) available now to illustrate how to create a plugin for Module Federation using Nx with Vite! This is something that we are monitoring and may provide an out-of-the-box solution to this in a future release!
+
+## Nx Release Updates
+
+Nx 17 launched with the new `nx release` capability in the Nx CLI. Since then we've been streamlining the experience, accounting for various edge cases and release scenarios. (extensive docs are being worked on rn ;)
+
+To give you full flexibility, in 17.2, we’ve added a programmatic API, which will allow you to easily write custom release scripts:
+
+```ts
+import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';
+
+(async () => {
+  const { workspaceVersion, projectsVersionData } = await releaseVersion({
+    specifier: 'minor',
+  });
+  await releaseChangelog({
+    versionData: projectsVersionData,
+    version: workspaceVersion,
+  });
+  await releasePublish();
+  process.exit(0);
+})();
+```
+
+This script above demonstrates how you can use this API to create your own script for updating your workspace’s version, then creating a changelog, and then publishing your package!
+
+We’ve also added first class support for independently released projects, meaning you can now target a specific project for release with the `--projects` command. For example, you can create a new version for just one project in your workspace with the command:
+
+```shell
+nx release version patch --project=my-project
+```
+
+## Angular 17 (AND NgRx 17) Support
+
+![](/blog/images/2023-12-20/bodyimg2.webp)
+
+[Angular](https://angular.dev/) is in the middle of [a HUGE renaissance](https://blog.angular.io/introducing-angular-v17-4d7033312e4b), between their new logo, new docs site, and introduction of some awesome features like Signals.
+
+Nx is here to support the transition! Nx has always been a great fit for Angular, and now supports Angular 17 as well as NgRx 17.
+
+To automatically migrate existing workspaces to Angular v17, run the commands:
+
+```shell
+nx migrate latest
+nx migrate --run-migrations
+```
+
+You can also use the `--interactive` flag if you want to migrate your workspace to the latest version of Nx while staying on your current version of Angular:
+
+```shell
+> nx migrate latest --interactive
+✔ Do you want to update to TypeScript v5.2? (Y/n) · true
+✔ Do you want to update the Angular version to v17? (Y/n) · false
+
+ >  NX   The migrate command has run successfully.
+
+   - package.json has been updated.
+   - migrations.json has been generated.
+
+ >  NX   Next steps:
+
+   - Run 'nx migrate --run-migrations'
+```
+
+## Smart Monorepos — Fast CI
+
+We just gave our Nx homepage a small facelift, including a new tagline, subtagline and illustration to better reflect Nx’s mission statement.
+
+![](/blog/images/2023-12-20/bodyimg3.webp)
+
+When you enter the monorepo space, having good local development experience and tooling to support you is one thing, scaling is the other. And scaling comes with multiple challenges, from scaling teams working on the monorepo to maintaining high throughput on CI.
+
+The latter is a common headache and we’ve seen companies struggle. With Nx we’re moving into the direction of becoming your e2e solution for monorepos, where we don’t just cover your local dev experience, but also provide robust and scalable solutions on CI.
+
+![](/blog/images/2023-12-20/bodyimg4.webp)
+
+We’re super excited to have launched “Nx Agents” to Early Access. If you haven’t seen Victor’s video yet about how he reduced e2e tests from 90 minutes to 10, then make sure to [check it out](/ci/features/distribute-task-execution).
+
+**“Nx Agents”** are the next iteration of DTE, providing a more flexible, cost effective and more performant approach to distribution on CI. This includes things like being able to dynamically allocate machines based on the size of the PR and flaky task detection and re-running. Also, it can be configured with a single line:
+
+```yaml
+- name: Start CI run
+  run: 'npx nx-cloud start-ci-run --distributes-on="8 linux-medium-js"'
+  ...
+```
+
+You can run Nx Agents on any CI provider. If you’re curious, [sign up for early access](https://go.nx.dev/nx-agents-ea)!
+
+## New Canary Releases
+
+We’ve added a new npm release tag: canary!
+
+![](/blog/images/2023-12-20/bodyimg5.webp)
+
+This canary release is created via a [cron job](https://github.com/nrwl/nx/blob/master/.github/workflows/publish.yml#L5C61-L5C61) that will regularly publish the current contents of the master branch of Nx.
+
+You can give the canary version a try new for a new workspace using the command:
+
+```shell
+npx create-nx-workspace@canary
+```
+
+This should be useful for previewing new not-yet released features!
+
+## Upcoming Release Livestream
+
+{% youtube src="https://www.youtube.com/embed/OXXTUjSO1hs?si=iDFETYdpg-0BrAIP" title="Nx 17.2 Release Livestream" /%}
+
+We’re going live in January with the Nx team to go over these updates as well! Be sure to click the link to get notified when we go live! And feel free to come with your questions in the chat!
+
+## Automatically Update Nx
+
+Updating Nx and its plugins is easy as we ship an [automated migration command](/features/automate-updating-dependencies).
+
+```shell
+npx nx migrate latest
+```
+
+After updating your dependencies, run any necessary migrations.
+
+```shell
+npx nx migrate --run-migrations
+
+```
+
+## Wrapping up
+
+That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to our [YouTube channel](https://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2023-12-28-highlights-2023.md b/docs/blog/2023-12-28-highlights-2023.md
new file mode 100644
index 0000000000..a98bbd7888
--- /dev/null
+++ b/docs/blog/2023-12-28-highlights-2023.md
@@ -0,0 +1,391 @@
+---
+title: Nx — Highlights of 2023
+authors: [Juri Strumpflohner, Victor Savkin, Zack DeRose]
+cover_image: /blog/images/2023-12-28/featured_img.png
+tags: [nx, nx-cloud]
+---
+
+It is that time again: getting flooded by Year of Review blog posts. We did it last year, and we should do it again! So here we go, and be warned, 2023 was massive!!
+
+**Table of Contents**
+
+- [Top 10 Nx Highlights of 2023](#top-10-nx-highlights-of-2023)
+  - [TypeScript for Extensibility — Rust for Speed](#typescript-for-extensibility-rust-for-speed)
+  - [First Class Vite Support](#first-class-vite-support)
+  - [Nx’t Level Publishing](#nxt-level-publishing)
+  - [Improved Node Backend Development: Fastify and Docker](#improved-node-backend-development-fastify-and-docker)
+  - [Nx Console support for IntelliJ](#nx-console-support-for-intellij)
+  - [Playwright for e2e testing](#playwright-for-e2e-testing)
+  - [TypeScript Packaging and Batch Mode](#typescript-packaging-and-batch-mode)
+  - [Nx team maintained Vue plugin](#nx-team-maintained-vue-plugin)
+  - [Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support](#extending-nx-local-generators-build-your-own-cli-verdaccio-support)
+  - [Module Federation](#module-federation)
+- [Many OSS repos adopt Nx](#many-oss-repos-adopt-nx)
+- [Nx Community](#nx-community)
+- [New Content & Improved Docs](#new-content-improved-docs)
+- [New Tagline: Smart Monorepos — Fast CI](#new-tagline-smart-monorepos-fast-ci)
+- [Nx Conf](#nx-conf)
+- [Looking ahead — 2024](#looking-ahead-2024)
+  - [Solving CI](#solving-ci)
+  - [Solving the Simplicity vs Power Dilemma](#solving-the-simplicity-vs-power-dilemma)
+
+## Top 10 Nx Highlights of 2023
+
+We shipped a ton of features in 2023. You can find all our release blog posts and release-related info here: [https://nx.dev/changelog](https://nx.dev/changelog) or check out our [Dev.to collection](https://dev.to/nx).
+
+We've picked out 10 highlights for you.
+
+### TypeScript for Extensibility — Rust for Speed
+
+At Nx, we’ve heavily embraced Typescript from the beginning and we’ve been very happy with that decision. Nx also stands as the [fastest JS monorepo tool](https://github.com/vsavkin/large-monorepo) available, demonstrating that adopting TypeScript does not necessarily compromise speed. However, we don’t stop here. To push the boundaries further, we started to rewrite the most performance critical and computationally intensive parts of the Nx core in Rust.
+
+Our initial focus was on [rewriting the task hasher](https://dev.to/nx/nx-158-rust-hasher-nx-console-for-intellij-deno-node-and-storybook-27ng#rustifying-the-nx-hasher), previously reliant on Git with a Node fallback. This shift to Rust brings a noticeable performance boost, particularly in large repositories, while maintaining the same user experience.
+
+Following this, we revamped the TypeScript dependency resolution, observing an almost 5x speed increase with our Rust-based approach over the traditional TSC method.
+
+{% tweet url="https://twitter.com/juristr/status/1726977598218199302" /%}
+
+Such enhancements are especially crucial for the efficient [project graph calculation](https://nx.dev/features/explore-graph). As we continue to evolve Nx, Rust will play a key role in optimizing performance-critical components. This strategic use of Rust complements our ongoing commitment to TypeScript, ensuring Nx remains as extensible and powerful as ever.
+
+### First Class Vite Support
+
+Vite is rapidly transforming the landscape of frontend development! Its refreshing simplicity and innovative approach have made a significant mark in the developer community. What truly stands out is not just Vite’s technological aspect but also how its team approaches and grows the community around the tool. Vite stands for speed and community, values that deeply resonate with us here at Nx.
+
+Our collaboration with our friends in the Vite core team has been incredibly fruitful. Vite is not just compatible but a first-class option with many of Nx’s frontend plugins. When you create a new Nx powered React workspace, Vite (and [Vitest](https://vitest.dev/)) are your default options.
+
+![](/blog/images/2023-12-28/bodyimg1.webp)
+
+We also built some powerful code generators that not only facilitate a seamless [transition from Webpack to Vite](https://nx.dev/nx-api/vite/generators/configuration#nxviteconfiguration) but also pave the way for an effortless [migration from a CRA-based setup](https://nx.dev/recipes/adopting-nx/adding-to-existing-project) to a modern Nx + Vite based workspace. To see this process in action, [check out this short video](https://www.youtube.com/watch?v=zvYb7XCLQzU).
+
+[AnalogJS](https://analogjs.org/) — the fullstack Angular meta-framework which also heavily builds on top of Vite — is using the `@nx/vite` plugin to power its Angular and Nx based workspaces.
+
+We also spoke at both editions of [ViteConf](https://viteconf.org/23/). If you’re curious check out [Juri’s talk about High Speed Monorepos](https://www.youtube.com/watch?si=A5Nkg3rxe3DlODc4&v=TiU-hdn7_To&feature=youtu.be) and this year’s talk by [Katerina on Streamlining your Vite dev flow with Nx](https://www.youtube.com/watch?si=A5Nkg3rxe3DlODc4&v=TiU-hdn7_To&feature=youtu.be).
+
+### Nx’t Level Publishing
+
+Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we’ll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like [release-it](https://github.com/release-it/release-it), [changesets](https://github.com/changesets/changesets), or custom Node scripts, similar to our approach in the Nx repository.
+
+However, many in our community have expressed a desire for a more native, integrated experience for versioning and publishing, akin to what Lerna offers. In response to this feedback, we’ve introduced [the “nx release” command](https://nx.dev/features/manage-releases), a solution designed to seamlessly integrate these processes into the Nx workflow.
+
+James Henry gave a deep dive talk of an early version of it at this year’s Nx Conf:
+
+{% youtube src="https://www.youtube.com/embed/p5qW5-2nKqI" /%}
+
+Since its introduction, the “nx release” feature has significantly evolved, leveraging the power of the Nx project graph to effectively understand inter-package dependencies. This understanding is crucial as it allows for:
+
+- Versioning packages offering support for both independent and “locked” versioning strategies.
+- Releasing packages in the correct sequence, ensuring dependency integrity.
+
+Beyond these core functionalities, the feature also includes a robust grouping mechanism, supports semantic versioning, and changelog generation. Additionally, it provides various release targets, such as GitHub and NPM. For those having special requirements, the [programmatic API](https://nx.dev/features/manage-releases#using-the-programmatic-api-for-nx-release) offers maximum flexibility.
+
+### Improved Node Backend Development: Fastify and Docker
+
+Colocating frontend and backend code within the same monorepo has become a popular practice. It greatly facilitates cross-functional teams and helps ensure end-to-end type safety. Although you can use [other backend stacks](https://www.nx-dotnet.com/) with Nx, Node is a popular backend companion for JS based frontends. We had support for [Express](https://expressjs.com/) and [NestJS](https://nestjs.com/) backend for a while.
+
+This year we added another popular option: [Fastify](https://fastify.dev/). Known for its high performance, excellent developer experience, and useful built-in features like logging, Fastify aligns well with Nx’s modular software design principles. Its extensible and modular nature complements the Nx philosophy perfectly.
+
+{% youtube src="https://www.youtube.com/embed/LHLW0b4fr2w?si=WeTqm5msQxssQ_d3" /%}
+
+In tandem with Fastify, we’ve also introduced [Docker support](https://youtu.be/LHLW0b4fr2w?feature=shared) for Node deployments.
+
+### Nx Console support for IntelliJ
+
+Nx Console has evolved from an experimental side project of the Nx team to a core part for enhancing your productivity when working in a monorepo. Being integrated right into your editor it can provide useful information and functionality right where you need it, whether that’s running commands, [providing contextual autocomplete support](https://twitter.com/juristr/status/1653032530474565638) or the ability to explore the project and task graph.
+
+![](/blog/images/2023-12-28/bodyimg2.webp)
+
+This year we not only added a lot of new features to Nx Console, but also rewrote its [internals](https://blog.nrwl.io/nx-console-gets-lit-ca339743ff4f) which paved the way to expand Nx Console to other code editors: **JetBrains IDEs.**
+
+Yes, this means you can now use the latest Nx Console directly in your [Webstorm IDE](https://www.jetbrains.com/webstorm/). Read the [announcement blog post](https://blog.nrwl.io/expanding-nx-console-to-jetbrains-ides-8a5b80fff2d7) for all the details or go ahead and install Nx Console if you didn’t already:
+
+- [Nx Console for VSCode](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
+- [Nx Console for IntelliJ](https://plugins.jetbrains.com/plugin/21060-nx-console)
+
+### Playwright for e2e testing
+
+2023 saw Nx introduce official support for [Playwright](https://playwright.dev/) — a popular testing tool from Microsoft.
+
+In this video, Zack DeRose explains how you can use Playwright to test both a single web application, as well as stand up a full-stack system — including a backend server and a frontend application — and write and run tests using Playwright:
+
+{% youtube src="https://www.youtube.com/embed/k1U3PuBrZFQ" /%}
+
+The repo for this video can also be found [here](https://github.com/nrwl/tic-tac-toe-playwright).
+
+Generally, Playwright fits in the Nx ecosystem as a tool that developers can use as a possible alternative to Cypress — a popular e2e testing tool that Nx has supported for a long time now! In addition to publishing an official [@nx/playwright package](https://www.npmjs.com/package/@nx/playwright), running the command to create a new workspace will now prompt for Playwright as an option for React, Angular, and Vue stacks:
+
+```shell
+$ npx create-nx-workspace@latest
+> NX   Let's create a new workspace [https://nx.dev/getting-started/intro]
+✔ Which stack do you want to use? · react
+✔ What framework would you like to use? · none
+✔ Integrated monorepo, or standalone project? · integrated
+✔ Which bundler would you like to use? · vite
+? Test runner to use for end to end (E2E) tests …
+Cypress [ https://www.cypress.io/ ]
+Playwright [ https://playwright.dev/ ]
+None
+```
+
+Similar options will appear when using Nx generators to create new frontend web applications for an existing workspace.
+
+### TypeScript Packaging and Batch Mode
+
+TypeScript has won. It has become the prevalent way of writing modern JavaScript applications. And we kept improving our support to streamline development and polish some of the rough edges. Like properly defining secondary package entry points. You can define them in the `package.json`, but both creating these entries but especially maintaining them can be quite painful.
+
+```
+{
+  "exports": {
+    "./package.json": "./package.json",
+    ".": "./src/index.js",
+    "./foo": "./src/foo.js",
+    "./bar": "./src/bar.js"
+  }
+}
+```
+
+So in [v16.8](https://blog.nrwl.io/nx-16-8-release-e38e3bb503b5#7b41) we added the ability to automatically have these generated for you by defining the `additionalEntryPoints` and `generateExportsField` when using the `@nx/js` plugin.
+
+```
+// packages/my-awesome-lib/project.json
+{
+  "name": "my-awesome-lib",
+  "targets": {
+    "build": {
+      "executor": "@nx/js:tsc",
+      ...
+      "options": {
+        "main": "packages/my-awesome-lib/src/index.ts",
+        ...
+        "additionalEntryPoints": ["packages/my-awesome-lib/src/foo.ts"],
+        "generateExportsField": true
+      },
+    },
+    ...
+  }
+}
+```
+
+Similarly we improved the ability to package your TS libraries in multiple formats (ESM and CJS). When using the `@nx/rollup` plugin, all you need to do is define the `format` property in your config:
+
+```
+// packages/my-awesome-lib/project.json
+{
+  "name": "my-awesome-lib",
+  "targets": {
+    "build": {
+      "executor": "@nx/rollup:rollup",
+      ...
+      "options": {
+        "main": "packages/my-awesome-lib/src/index.ts",
+        ...
+        "format": ["esm", "cjs"],
+        "additionalEntryPoints": ["packages/my-awesome-lib/src/foo.ts"],
+        "generateExportsField": true
+      },
+    },
+    ...
+  }
+}
+```
+
+Here’s a video that walks you through:
+
+{% youtube src="https://www.youtube.com/embed/Vy4d0-SF5cY?si=mHatqRPRqHAK0X9o" /%}
+
+But we wouldn’t be talking about Nx if we didn’t also look into speeding up TypeScript compilation for large monorepos. We called it “[batch mode](https://nx.dev/showcase/benchmarks/tsc-batch-mode)”. When enabling batch mode, Nx leverages the underlying [project graph](https://nx.dev/features/explore-graph) to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to [our benchmarks](https://github.com/nrwl/large-ts-monorepo), batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.
+
+![](/blog/images/2023-12-28/bodyimg3.gif)
+
+### Nx team maintained Vue plugin
+
+After adding Vite as a first-class citizen of Nx workspaces, it was only a matter of time before Nx started offering official support to Vue!
+
+Vue is currently the second most popular frontend framework (according to npm downloads) behind React and slightly ahead of Angular.
+
+![](/blog/images/2023-12-28/bodyimg4.webp)
+
+The first place your might notice Nx’s support for Vue is in the `create-nx-workspace` script:
+
+![](/blog/images/2023-12-28/bodyimg5.webp)
+
+The option above will create a new Nx workspace with a fresh new Vue application, all set up and ready to develop! To add new Vue projects to an existing Nx workspace, you can also add our `@nx/vue` package as a dev dependency to your workspace:
+
+```shell
+% npm add -D @nx/vue
+```
+
+And you’ll then have access to Nx generators so you can create Vue applications, libraries, and more in your workspace!
+
+![](/blog/images/2023-12-28/bodyimg6.gif)
+
+Checkout out our [Vue standalone tutorial](https://nx.dev/getting-started/tutorials/vue-standalone-tutorial) for more, as well as our [Vue API docs](https://nx.dev/nx-api/vue), and stay tuned as Nx prepares to offer more Vue support (including support for [Nuxt](https://nuxt.com/), a full-stack framework built around Vue) in the near future!
+
+### Extending Nx: Local Generators, Build your Own CLI, Verdaccio Support
+
+Extensibility is at the heart of Nx, serving as the cornerstone of its flexibility. It enables the Nx core team to continually expand capabilities through dedicated plugins and simultaneously paves the way for a rich array of [community plugin contributions](https://nx.dev/plugin-registry). Furthermore, Nx’s adaptable nature is particularly beneficial for large enterprises, as it allows for the creation of custom automation solutions, specifically tailored to meet their unique organizational needs.
+
+In 2023 we kept improving Nx’s extensibility, unifying the Nx plugin development model and how you develop workspace-local automations. You can now scaffold a new plugin into your Nx workspace and run it right away which makes it an interesting approach to automate your monorepo.
+
+{% youtube src="https://www.youtube.com/embed/myqfGDWC2go?si=q6_9JReS1nF8d3pZ" /%}
+
+When creating automations with Nx you cannot just enhance existing Nx workspaces, but also develop a complete [Nx preset](https://nx.dev/extending-nx/recipes/create-preset) that controls the entire appearance of an Nx workspace. Basically your own, personalized `create-nx-workspace`. You can publish and then use your preset like:
+
+```shell
+npx create-nx-workspace myrepo --preset=@yourpkg/nx-preset
+```
+
+We wanted to make building on top of Nx even more pleasant, allowing you to introduce your own branding by [building your own CLI with Nx](https://www.youtube.com/watch?v=ocllb5KEXZk). The [Qwik-Nx](https://github.com/qwikifiers/qwik-nx) repo is a great example where they allow you to scaffold a new Nx workspace for Qwik development with:
+
+```shell
+npx create-qwik-nx
+```
+
+And finally, we extracted our own [Verdaccio](https://verdaccio.org/) setup that we’ve been using to run our e2e tests in the [Nx repo](https://github.com/nrwl/nx) s.t. you can use it for your own plugin development as well. Check out [this video](https://www.youtube.com/watch?v=t1c925TzrzE) for a walkthrough on how this works.
+
+### Module Federation
+
+[Module Federation](https://medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669) is an exciting new feature of Webpack 5 that has gained a significant amount of interest in 2023.
+
+Simply put, Module Federation allows a Javascript application running in a browser to dynamically load code from another application hosted at a different url, while facilitating optimal loading of shared dependencies.
+
+This is an exciting development as it allows a paradigm shift in how you can architect, build, and deploy Javascript applications! And this is especially exciting for monorepo fans, as Nx has best-in-class support for module federation that makes a Module Federation approach easy to adopt and simple to understand!
+
+Currently, our `@nx/angular` and `@nx/react` plugins both have generators to [create a “host” application](https://nx.dev/recipes/module-federation/create-a-host) that will load and consume federated modules from [“remote” applications](https://nx.dev/recipes/module-federation/create-a-remote), which you can also generate using Nx. Then, by running a simple command with Nx, you can serve all applications required for your host application with the command:
+
+```shell
+nx serve host-application --devRemotes=remote-application
+```
+
+Where in the example above your host application is named “host-application” and a remote application that you want live updates on as you’re developing is named “remote-application”.
+
+Throughout 2023, we’ve continued to increase Nx’s support and general dev experience around Module Federation, including [adding a generator to federate an existing module](https://nx.dev/recipes/module-federation/federate-a-module), improving the local developer experience by improving local webserver performance, and introducing the concept of [Dynamic Module Federation](https://nx.dev/recipes/angular/dynamic-module-federation-with-angular#advanced-angular-micro-frontends-with-dynamic-module-federation) which will allow you to dynamically specify the location of your remote applications via a “module-federation.manifest.json” file!
+
+At Nx, we’re excited about the Module Federation support we offer for our users, and think that it has many interesting applications when paired with Nx’s CI capabilities, in particular allowing for [much shorter build times](https://nx.dev/concepts/module-federation/faster-builds-with-module-federation#faster-builds-with-module-federation) especially for larger Angular applications.
+
+## Many OSS repos adopt Nx
+
+By simply installing the `nx` package (or initializing with `nx init` in any project or monorepo), you already get some cool features:
+
+- Advanced task scheduling, including task pipelines and parallel execution.
+- Efficient caching mechanisms.
+
+> If you want to learn more about such setup, make sure to check out our blog post on [how to adopt Nx on a npm/yarn/pnpm workspace](https://dev.to/nx/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx-1eem) or the corresponding [video version](https://www.youtube.com/watch?si=0XH6Sp025xM3Rru5&v=ngdoUQBvAjo&feature=youtu.be).
+
+Numerous open-source packages are adopting Nx in this lightweight manner. It enables them to maintain their existing setup while notably enhancing the local developer experience (DX) in task execution and accelerating processes on CI.
+
+I picked out some of the more well-known OSS repos that started using Nx this year:
+
+[**Tanstack**](https://tanstack.com/) — Tanstack has evolved to an entire ecosystem consisting of the famous [Tanstack (or React) Query](https://github.com/tanstack/query), [Tanstack Table](https://github.com/tanstack/table), now also [Tanstack Router](https://github.com/tanstack/router) and [Tanstack Form](https://github.com/tanstack/form). It started with Tanstack Query, which adopted Nx and Nx Cloud. [Zack talked about this collab with Dominik](https://www.youtube.com/watch?v=NvPXK6DVZGE), and we also had [Dominik](https://twitter.com/TkDodo) on our [Nx live stream](https://www.youtube.com/live/IbU6b6s0H1Q?si=0QZexPwulLXB9FIN). Now, all the above-mentioned Tanstack libs have adopted Nx, and there’s more coming.
+
+[**Sentry JavaScript**](https://github.com/getsentry/sentry-javascript/) — Sentry, renowned for its comprehensive solutions in frontend monitoring and error logging, recently adopted Nx for their [official JavaScript SDK](https://github.com/getsentry/sentry-javascript/). This move integrates Nx’s capabilities into their monorepo, containing packages for popular frontend and Node.js backend integrations. They also published a blog post on [the benefits they’ve seen following the adoption of Nx in their monorepo](https://sentry.engineering/blog/reduce-ci-time-with-nx-caching) (hint: reducing CI times by 35%).
+
+[**RxJS**](https://github.com/ReactiveX/rxjs) — The library for reactive programming in JavaScript. It is widely popular, with over 40 million downloads/week on NPM. RxJS only recently adopted Nx, not only leveraging speed improvements via caching, but also leveraging Nx’s latest `nx release` feature to publish packages to NPM.
+
+[**AnalogJS**](https://analogjs.org/) — Analog is a full-stack Angular meta-framework that brings exciting features to Angular, like faster Vite setup, support for both server-side and static rendering, and easy file-based routing. Analog uses an Nx monorepo for its development and also uses [Nx’s DevKit](https://nx.dev/extending-nx/intro/getting-started) to create tools that work great in both Nx and Angular CLI workspaces.
+
+[**Qwikifier**](https://github.com/qwikifiers/qwik-nx) — The Qwikifiers community built a dedicated Nx plugin to combine the power of Qwik and Nx. Their repo is a great example of building Nx plugins and [using Nx to build your own CLI](https://nx.dev/extending-nx/recipes/create-install-package).
+
+[**Builder.io Mitosis**](https://github.com/BuilderIO/mitosis) — [BuilderIO](https://www.builder.io/) has an ambitious compiler project that allows you to write a component once and then compile it to different frameworks. Check out their [mind-blowing demo page](https://mitosis.builder.io/?outputTab=G4VwpkA%3D). They adopted Nx to [coordinate task dependencies](https://nx.dev/concepts/task-pipeline-configuration) and speed up their CI builds.
+
+[**Ghost**](https://github.com/TryGhost/Ghost) — Are you into blogging? You might want to look at [Ghost](https://ghost.org/). They were using Lerna in the past and migrated to a fully Nx-powered workspace.
+
+And these are just some of them that joined in 2023. If I missed some cool ones (which I’m pretty sure), [ping me](https://twitter.com/juristr) and let me know!
+
+## Nx Community
+
+Nx has a huge community! We’re lucky to have so many folks rooting for Nx, whether on socials, talking at conferences, writing blog posts or [creating awesome plugins](https://nx.dev/plugin-registry).
+
+**Nx Champions** — This year we finally launched which we had planned for a long time. Our [Nx Champions](https://nx.dev/community) program.
+
+![](/blog/images/2023-12-28/bodyimg7.webp)
+
+These are individuals who stood out for their contributions and passion for helping within the Nx community. We wanted to build a more connected relationship with these folks and have a channel to gather more direct feedback as well. Get to know [all of our champions](https://nx.dev/community).
+
+**New Discord server** — Around September we also switched over from our previous Nx Slack community to a brand new [**Nx community Discord**](https://go.nx.dev/community), which is already 2,600 members and counting. Discord is popular among OSS communities and allows new folks to join easily. In addition, we now have a dedicated forum integrated, as well as a couple of useful automations. More coming next year!
+
+Make sure [you join](https://go.nx.dev/community)!
+
+## New Content & Improved Docs
+
+Our [Youtube channel](https://www.youtube.com/@nxdevtools) has grown to over 15k subscribers and peaks of 65k views a month. We love to provide educational video content, so make sure to subscribe! It got a little silent towards the end of the year, but we’ve been working a lot behind the scenes. So stay tuned!
+
+We also poured a lot of [effort into the docs](https://nx.dev/getting-started/intro). We restructured them following the [Diataxis](https://diataxis.fr/) to make pages less overwhelming and more structured based on their type of content. You’ll find
+
+- [**Concept docs**](https://nx.dev/concepts) — which explain some of the inner workings and mental model behind certain features. Like [how caching works](https://nx.dev/concepts/how-caching-works).
+- [**Recipes**](https://nx.dev/recipes) — which are solution oriented. You already know how to cook, we provide the exact recipe for it.
+- [**Tutorials**](https://nx.dev/getting-started/tutorials) — for when you just want to sit down and follow along, step by step to learn how to use Nx in a certain context.
+- [**Reference**](https://nx.dev/reference) and [**API docs**](https://nx.dev/nx-api) — pure, raw and to the point.
+
+We created a brand new [“Why Nx”](https://nx.dev/getting-started/why-nx) page explaining the overall architecture of Nx including a [brand new video](https://www.youtube.com/watch?v=-_4WMl-Fn0w) giving you a holistic overview of what Nx is capable of.
+
+We also refreshed our [entry pages](https://nx.dev/getting-started/intro), including dedicated examples of using Nx with popular stacks:
+
+![Examples include Express, Vue, Next, Nuxt, Rract Native, Rust, Go, Storybook, and more.](/blog/images/2023-12-28/bodyimg8.webp)
+
+You can also browse them in the [nx-recipes](https://github.com/nrwl/nx-recipes) GitHub repository.
+
+{% tweet url="https://twitter.com/juristr/status/1736023402933318011" /%}
+
+{% tweet url="https://twitter.com/juristr/status/1726977598218199302" /%}
+
+And obviously, we jumped on the AI train as well. A couple of months ago, we added the [Nx Assistant](https://nx.dev/ai-chat). A ChatGPT-powered interface trained on our docs. [Katerina](https://twitter.com/psybercity) wrote about it [on our blog](https://blog.nrwl.io/nx-docs-ai-assistant-433d238e45d4). The AI chat allows to interactively ask questions about Nx and will give you relevant answers from our docs (including linking to the sources).
+
+## New Tagline: Smart Monorepos — Fast CI
+
+Nx stands out for its flexibility, accommodating for both monorepo and non-monorepo project structures. This approach allows users to begin with simpler project configurations, leveraging the benefits of Nx’s robust tooling, and later, when the need arises, seamlessly [migrate to a monorepo](https://nx.dev/recipes/tips-n-tricks/standalone-to-integrated).
+
+However, Nx’s true strength becomes most apparent at scale, typically within a monorepo setup. We wanted to capture it in our new tagline: **Smart Monorepos — Fast CI**.
+
+{% twitter url="https://twitter.com/juristr/status/1734558895547568634" /%}
+
+Setting up an efficient and maintainable CI process for monorepos can be a complex task, so we’ve also made it a focal point in our new tagline. Nx expands beyond the local development experience, helping you set up an efficient CI process. We’re publicly launching [Nx Agents](https://nx.dev/ci/features/distribute-task-execution) to add seamless distribution to your CI pipeline, and more are coming in 2024.
+
+As part of that, we also restructured our docs to have a section entirely dedicated to CI: [https://nx.dev/ci](https://nx.dev/ci/intro/ci-with-nx).
+
+## Nx Conf
+
+We did it again! The second in-person Nx Conf was a resounding success, this time set against the vibrant backdrop of the Big Apple.
+
+![](/blog/images/2023-12-28/bodyimg9.webp)
+
+There’s not much to say. Check out some of the amazing talks. I did a [Nx Conf 2023 recap blog post](https://dev.to/nx/nx-conf-2023-recap-53ep).
+
+## Looking ahead — 2024
+
+Although we shipped a lot in 2023, in many ways 2023 was about preparing for what we are planning to ship in Q1 2024.
+
+### Solving CI
+
+Legacy CI systems are a performance and productivity bottleneck if you use a powerful build system like Nx. Big tech companies know it and that’s why their CI systems look nothing like Circle or Jenkins. We’ve been narrowing this gap over the years, but only this year we finally built a turn-key CI solution that gives you great performance, scalability, dev ergonomics, and must better cost efficiency.
+
+It has three components:
+
+- [**Nx Cach**](https://nx.dev/ci/features/remote-cache): Built-in local and remote caching to speed up your tasks and save you time and money. Available now.
+- [**Nx Agents**](https://nx.dev/ci/features/distribute-task-execution): A single line to enable distributed computation, across multiple machines. Fully managed agents, dynamically allocated based on PR size. Available early Feb.
+- **Nx Workflows**: Next generation, fully managed CI solution with distribution at its core, designed from the ground up for monorepos. _Available later in 2024._
+
+Optimal parallelization and distribution, using the right numbers of agents for each PR, rerunning flaky tests, splitting and distributing large test suites, handling dependencies between tasks across machines — are just some of the things we can now handle automatically for you. Turn it on and enjoy the speed.
+
+### Solving the Simplicity vs Power Dilemma
+
+Balancing simplicity and power is the trickiest part of the dev tools design. Simple onboarding for small projects or handling the biggest enterprise systems? Two years ago we solved this problem by giving you a choice between the package-based setup (a more powerful version of something like Turborepo) and the integrated setup (we manage your whole monorepo in the most optimal way). But now we believe we have a much better solution, where you have both, the simplicity of the former with the power of the latter. So you no longer have to choose.
+
+We took inspiration from VSCode. Any project you open in VSCode will work right away: it is simple, and you don’t need to configure anything. If you install say a Playwright plugin, VSCode becomes aware of Playwright. It can run and debug your tests right in the editor. That’s what the Nx experience is going to be like. Any project, any tool will work right away. But if you — for instance — install the Playwright plugin, Nx will become aware of Playwright and will be able to cache test runs in the most optimal way and distribute your e2e tests across machines for best efficiency. All the benefits with none of the costs.
+
+The whole team is excited about it as the new experience feels much more elegant.
+
+As always, we try very hard not to break folks, so all your current workspaces will keep working, and we will [provide automatic migrations](https://nx.dev/features/automate-updating-dependencies) to bring you to this new way of using Nx.
+
+Exciting stuff! So keep an eye on our channels, and subscribe if you haven’t already ;)
+
+---
+
+## Learn more
+
+- [Nx Docs](https://nx.dev/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools)
+- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2024-02-05-nx-18-project-crystal.md b/docs/blog/2024-02-05-nx-18-project-crystal.md
new file mode 100644
index 0000000000..14126cc6f3
--- /dev/null
+++ b/docs/blog/2024-02-05-nx-18-project-crystal.md
@@ -0,0 +1,187 @@
+---
+title: What if Nx Plugins Were More Like VSCode Extensions
+authors: [Juri Strumpflohner]
+cover_image: '/blog/images/2024-02-05/featured_img.png'
+tags: [nx, releases]
+reposts: []
+---
+
+Enhance, but don’t interfere! That’s the ideal! And this is how extensions work in VSCode (or Webstorm). You can use VSCode without any extension and get some basic functionality, or you can add an extension on top to enhance your experience and, ideally, increase your productivity.
+
+Table of Contents
+
+- [Adding Nx to an Existing Monorepo](#adding-nx-to-an-existing-monorepo)
+- [Project Crystal](#project-crystal)
+- [Project Crystal Plugins in an Nx Monorepo](#project-crystal-plugins-in-an-nx-monorepo)
+  - [Inferred Targets](#inferred-targets)
+  - [Visualizing Inferred Targets](#visualizing-inferred-targets)
+- [More Transparency and a Single Source of Truth](#more-transparency-and-a-single-source-of-truth)
+- [Enhancing existing Monorepos with Nx Plugins](#enhancing-existing-monorepos-with-nx-plugins)
+- [This is just the Beginning](#this-is-just-the-beginning)
+- [Learn more](#learn-more)
+
+---
+
+**Prefer a video? We’ve got you covered!**
+{% youtube src="https://www.youtube.com/embed/wADNsVItnsM?si=sQ3-Dlx6KBRBUMkE" title="What if Nx Plugins Were More Like VSCode Extensions" /%}
+
+Also, make sure to check out [Launch Nx Conf](/launch-nx) on Thursday, Feb 8th, where we’ll have more in-depth talks about Project Crystal as well as other exciting features around Nx and Nx Cloud.
+
+---
+
+Take, for instance, the Playwright plugin. You install it, and it’ll automatically detect the Playwright config file and enhance your workspace by providing quick run buttons alongside your tests or even a dedicated Test Explorer window.
+
+![](/blog/images/2024-02-05/bodyimg1.webp)
+_The Playwright VSCode extension enhancing the developer experience_
+
+## Adding Nx to an Existing Monorepo
+
+You can add Nx to an existing npm/yarn/pnpm monorepo quite straightforwardly. You run:
+
+```shell
+npx nx@latest init
+```
+
+You’ll get an `nx` package installed and an `nx.json` allowing you to define [task dependencies](/recipes/running-tasks/defining-task-pipeline) and caching. With that, you're now able to run commands like `nx build <your project>` or nx `run-many -t build test` to run all `build` and `test` targets in your workspace in parallel. Nx will read and use your existing `package.json` scripts. I've written an in-depth [blog post about adopting Nx in such a scenario](https://dev.to/nx/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx-1eem).
+
+This is the most lightweight setup you can get while still getting some improvements via Nx regarding faster task running and more intelligent parallelization. But, you need to deal with the remaining of the monorepo setup.
+
+## Project Crystal
+
+Nx always had more to offer, though, which it mainly did through its plugins. They’re optional but usually something you’d get set up when creating a new workspace with `create-nx-workspace`. Nx Plugins are extremely powerful, helping you not only create and configure new monorepos, but also taking away the burden of integrating various tooling as well as providing features for enforcing consistency and helping with maintainability. These aspects are fundamental in enterprise settings, where Nx Plugins have proven to help teams successfully manage their monorepos.
+
+However, this is a balancing act. More abstraction and automation means more support but also potentially a learning curve and giving up some low-level control. It also requires a slightly more significant upfront investment when migrating to an Nx plugin-powered monorepo.
+
+**These are things we wanted to solve**, and **Project Crystal** is the first step in that direction.
+
+![](/blog/images/2024-02-05/bodyimg2.webp)
+
+Some of the main objectives of Project Crystal are to...
+
+- make Nx plugins more transparent
+- reduce the amount of configuration required
+- allow Nx plugins to be drop-in enhancements in existing npm/yarn/pnpm monorepos
+- allow for a migration to an Nx plugin-powered monorepo
+
+## Project Crystal Plugins in an Nx Monorepo
+
+> Note: starting with Nx 18, Project Crystal will be active for new workspaces only. You can opt-in to use them though.
+
+When you create a new Nx workspace using
+
+```shell
+npx create-nx-workspace myorg
+```
+
+... and you choose an “integrated monorepo” you’ll get the usual setup powered by Nx Plugins and all the features and benefits that come with them. Where you’ll see Project Crystal in action is when you open a `project.json` file, which will most likely look like the following:
+
+```json {% fileName="project.json" }
+{
+  "name": "reactapp",
+  "$schema": "../../node_modules/nx/schemas/project-schema.json",
+  "sourceRoot": "apps/reactapp/src",
+  "projectType": "application",
+  "targets": {},
+  "tags": []
+}
+```
+
+### Inferred Targets
+
+Starting with Nx 18 and Project Crystal, we don’t generate any targets anymore, but the corresponding Nx plugin instead [infers them](/concepts/inferred-tasks). If we open the `nx.json`, you'll see a new property, `plugins`:
+
+```json {% fileName="nx.json" %}
+{
+  ...
+  "plugins": [
+    {
+      "plugin": "@nx/vite/plugin",
+      "options": {
+        "buildTargetName": "build",
+        "previewTargetName": "preview",
+        "testTargetName": "test",
+        "serveTargetName": "serve",
+        "serveStaticTargetName": "serve-static"
+      }
+    },
+    {
+      "plugin": "@nx/eslint/plugin",
+      "options": {
+        "targetName": "lint"
+      }
+    },
+    {
+      "plugin": "@nx/cypress/plugin",
+      "options": {
+        "targetName": "e2e",
+        "componentTestingTargetName": "component-test"
+      }
+    },
+    ...
+  ],
+  ...
+}
+```
+
+Notice the options property defining the names of the potentially inferred targets for each plugin. These targets will be generated dynamically s.t. you can still run `nx build reactapp` even though there's no `build` target explicitly defined in the `project.json` of your `apps/reactapp` project.
+
+This dramatically reduces the redundancy of repeatedly configuring the same tasks (e.g., Jest or Vitest tasks) throughout your various projects. Instead, with this new approach, you get the defaults, and if you need to override them, you can still define them in your `project.json` file as you were accustomed to before.
+
+### Visualizing Inferred Targets
+
+Dynamically inferred targets help with the maintainability aspect and reduce the configuration overhead overall. But how do we know which targets are available for a given project?
+
+Option 1 is to run the following command:
+
+```shell
+npx nx show project reactapp --web
+```
+
+This opens your browser with the following view:
+
+![Browser view reads "reactapp, root: apps/reactapp, type: application" and shows a list of targets.](/blog/images/2024-02-05/bodyimg3.webp)
+_Browser view of the inferred targets_
+
+Option 2 is [Nx Console](/getting-started/editor-setup), which is an extension for VSCode as well as IntelliJ (Webstorm etc.). It comes with a project detail view, as shown below, as well as “Codelens” features that enhance your configuration files with context-based information and features.
+
+![](/blog/images/2024-02-05/bodyimg4.webp)
+_Nx Console showing the inferred targets in a dedicated view_
+
+## More Transparency and a Single Source of Truth
+
+We also wanted the new approach to plugins to be closer to the actual CLI tool of the framework you’re using. If you have a React + Vite project, `nx build` should be as close as possible to the `vite build` while still providing the enhancements around caching configuration.
+
+And this is what happens. Behind the scenes, the plugin configures caching with inputs and outputs and task dependencies (e.g., `^build`) but then mostly pipes through to the Vite CLI (in this particular case), Remix, Next CLI, etc.
+
+![](/blog/images/2024-02-05/bodyimg5.webp)
+
+Furthermore, the framework-specific config — in the example of Vite, the `vite.config.ts` - is the single source of truth from which Nx infers configuration such as caching. If you change your Vite `build.outDir`, Nx automatically picks that up and uses that as the caching output directory.
+
+## Enhancing existing Monorepos with Nx Plugins
+
+As mentioned earlier, one of the key goals of Project Crystal was to improve the adoption story of Nx Plugins, which implicitly also helps with migrating to Nx plugin-based monorepos. By reducing the config footprint of an Nx plugin and by automatically inferring tasks from existing framework configs, we’ve moved in a direction where plugins have become much more of a drop-in approach.
+
+Starting with Nx 18, if you now run `nx init` on an existing npm/yarn/pnpm workspace, you'll also get asked about installing plugins based on the setup you have in your monorepo.
+
+![](/blog/images/2024-02-05/bodyimg6.webp)
+_Asking about installing plugins based on your monorepo tooling_
+
+You can also obviously start with no plugin at all and incrementally add them as you go and feel comfortable using the new `add` command:
+
+```shell
+npx nx add @nx/vite
+```
+
+## This is just the Beginning
+
+We just released Project Crystal, so this is just the beginning of it. While we’ve moved many of our existing Nx plugins to adopt the new approach, there are still some more refinements to be done in the coming weeks. But we are excited about the possibilities Project Crystal enables for Nx and its adoption story going forward, making Nx plugins more approachable, transparent, and lightweight.
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2024-02-06-nuxt-js-support-in-nx.md b/docs/blog/2024-02-06-nuxt-js-support-in-nx.md
new file mode 100644
index 0000000000..6a06f87ef3
--- /dev/null
+++ b/docs/blog/2024-02-06-nuxt-js-support-in-nx.md
@@ -0,0 +1,189 @@
+---
+title: Introducing @nx/nuxt Enhanced Nuxt.js Support in Nx
+cover_image: '/blog/images/2024-02-06/featured_img.png'
+authors: ['Katerina Skroumpelou']
+tags: [devtools, javascript, monorepos, nuxt]
+---
+
+We're excited to introduce a new way to enhance your [Nuxt](https://nuxt.com/) development workflow! After the Vue plugin, we're introducing our new Nx plugin for Nuxt, `@nx/nuxt`. Designed for Nuxt developers and existing Nx users alike, this integration brings the best of both worlds into your development ecosystem, enabling you to leverage Nx's powerful capabilities seamlessly within your Nuxt projects.
+
+## Why Consider Nx for Your Nuxt Projects?
+
+Using Nx with your Nuxt.js projects presents the following advantages:
+
+- **Monorepo Management**: Simplify the management of multiple projects within a single repository, facilitating code sharing and reducing overhead.
+- **Modular Development**: Break down your Nuxt app into manageable, independent modules that can be developed, tested, and deployed in isolation.
+- **Enhanced Caching**: Accelerate your development with Nx's intelligent caching, automatically configured for your Nuxt projects.
+- **Nx generators**: Nx provides generators for scaffolding new Nuxt applications, with support for Jest, Storybook, and e2e test generation with Cypress or Playwright.
+- **Automated upgrades**: Nx offers a set of migrators that help you upgrade your projects.
+
+## Getting Started with Nx and Nuxt.js
+
+Whether you're initiating a new project or integrating into an existing one, `@nx/nuxt` offers a straightforward setup process:
+
+### Starting a New Nx Workspace with Nuxt
+
+Creating a new Nx workspace optimized for Nuxt is as simple as running:
+
+```shell
+npx create-nx-workspace@latest --preset=nuxt
+```
+
+Our setup wizard will guide you through the initial configuration, ensuring your workspace is tailored to your needs:
+
+```shell
+npx create-nx-workspace@latest
+
+ >  NX   Let's create a new workspace [/getting-started/intro)/getting-started/intro]
+
+✔ Where would you like to create your workspace? · my-org
+✔ Which stack do you want to use? · vue
+✔ What framework would you like to use? · nuxt
+✔ Integrated monorepo, or standalone project? · integrated
+✔ Application name · my-app
+✔ Test runner to use for end to end (E2E) tests · playwright (also cypress)
+✔ Default stylesheet format · scss (also css, less)
+✔ Set up CI with caching, distribution and test deflaking · github
+```
+
+This command will create a new Nx workspace with a single Nuxt application, complete with essential features and ready for development.
+
+## Enhancing an Existing Nuxt Project with Nx
+
+Integrating Nx into an existing Nuxt.js project has never been easier, with the help of the `nx init` command. This command will add Nx to your project without the need to disrupt your current setup.
+
+### How It Works
+
+When you run `nx init` in your existing Nuxt.js project, Nx does the following:
+
+- **Installs @nx/nuxt**: Adds the necessary Nx and @nx/nuxt dependencies to your project, enabling Nx's features while keeping your existing setup intact.
+- **Understands Existing Configurations**: Nx automatically recognizes your nuxt.config.js or nuxt.config.ts file, ensuring that all your custom configurations, scripts, and commands are preserved and utilized.
+- **Minimal Configuration**: Only a minimal `nx.json` file is added to your project. This file is used to configure the `@nx/nuxt` plugin if needed, but in most cases, your existing Nuxt.js configurations will suffice.
+
+To begin the integration process, simply navigate to the root of your existing Nuxt.js project and run:
+
+```shell
+npx nx init
+```
+
+This approach offers several key benefits for teams looking to adopt Nx:
+
+- **Zero Disruption**: Your project will continue to use its existing configurations, and the existing configuration entrypoint files. There's no need to learn new configuration syntaxes or reconfigure your project to start using Nx.
+- **Immediate Value**: Instantly gain access to Nx's powerful developer tools and build system, without significant changes to your project.
+- **Future Flexibility**: As your project grows, Nx is ready to scale with you. You can gradually adopt more Nx features and plugins over time, at a pace that suits your team.
+
+## Using Nx to run your Nuxt app
+
+Nx scans your workspace to look for Nuxt configuration files (eg. `nuxt.config.ts`). It uses these files to understand where your Nuxt projects live, and uses them to set up tasks that can be invoked through Nx, like `serve` and `build`. So, in your Nx workspace, you can then run:
+
+```shell
+nx serve my-nuxt-app
+```
+
+and
+
+```shell
+nx build my-nuxt-app
+```
+
+and these commands will call the `nuxt` CLI under the hood, enhanced with Nx's features.
+
+You can see a visual representation of your task dependencies by running
+
+```shell
+nx graph
+```
+
+![Task graph - build](/blog/images/2024-02-06/bodyimg1.png)
+
+You can also see how Nx configures your tasks, by running:
+
+```shell
+nx show project my-nuxt-app --web
+```
+
+![Project details](/blog/images/2024-02-06/bodyimg2.png)
+
+![Project details - individual task details](/blog/images/2024-02-06/bodyimg3.png)
+
+### Using Nx Console
+
+You get access to all these features through our VSCode and WebStorm [Nx Console extension](/getting-started/editor-setup).
+
+You can use Nx Console to visualize tasks, and understand where each inferred task (like `build` and `serve` in Nuxt's case) is coming from, with our codelens-like feature, as an alternative to the `--web` flag on the `nx show project` command.
+
+Nx Console is also very convenient for generating code and running tasks, since it offers a graphical user interface for all the amazing features of the Nx CLI.
+
+## What Does Nx Bring to Your Nuxt Development?
+
+With `@nx/nuxt`, your Nuxt projects gain automatic recognition of `build` and `serve` processes. There's no need to deal with unfamiliar configurations; Nx intuitively understands your Nuxt project structure and optimizes accordingly.
+
+### Modularize and Scale with Ease
+
+One of the most compelling aspects of using Nx with Nuxt.js is the ability to modularize large applications into manageable libraries or components. This not only makes your codebase more organized and maintainable but also significantly enhances your development workflow and CI processes.
+
+#### Breaking Down a Monolithic Nuxt App
+
+Large Nuxt applications can become challenging to maintain and scale over time. By adopting Nx, you can structure your Nuxt app as a collection of smaller, focused libraries. Each library can encapsulate specific functionalities or features, such as UI components, utilities, or business logic.
+
+#### Independent Development and Testing
+
+This modular structure allows teams to work on different aspects of the application in parallel, reducing bottlenecks and improving collaboration. Furthermore, you can run tests, linters, and other checks independently for each library, making your development process more efficient and targeted.
+
+For instance, if you want to create a new Vue UI library, you can use the following command:
+
+```shell
+nx generate @nx/vue:lib my-shared-ui
+```
+
+This command creates a my-shared-ui library within your workspace, which can then be used across your Nuxt app and potentially other applications within the same workspace.
+
+#### Enhancing CI with Modular Builds
+
+On the CI front, Nx's modular approach makes things much faster. You can configure your CI pipeline to build, test, and deploy only the affected libraries and applications, thanks to Nx's advanced dependency graph analysis. This results in faster CI runs and more efficient resource utilization.
+
+#### Sharing Code Between Applications
+
+Nx's workspace model facilitates code sharing between projects, which is particularly useful in monorepos containing multiple front-end projects. With Nx, sharing UI components, utilities, or services between these applications becomes straightforward.
+To share code, simply import the library into your Nuxt and Vue applications as needed. Nx takes care of the rest, ensuring that dependencies are correctly managed and that your applications remain buildable and testable.
+
+Imagine a scenario where your workspace contains a Nuxt application for your public-facing website and a Vue application for an internal tool. You can create a shared library for common UI components, such as buttons, inputs, and modals, and use these components in both applications. This not only reduces duplication but also ensures consistency across your projects.
+
+```ts
+// Importing a shared UI component in your Nuxt app
+import { MyButton } from '@my-org/my-shared-ui';
+```
+
+```ts
+// Importing the same component in your Vue app
+import { MyButton } from '@my-org/my-shared-ui';
+```
+
+### Visualizing Your Project Structure
+
+Nx provides a clear overview of your project's structure and dependencies, making it easier to manage complex applications. The Nx Console extension for VSCode, for instance, offers a graphical interface to visualize and run tasks, enhancing your development experience.
+
+In your workspace, you can run
+
+```shell
+nx graph
+```
+
+and see the structure of your projects:
+
+![A project graph](/blog/images/2024-02-06/bodyimg4.png)
+
+## Embracing Nx in Your Nuxt Journey
+
+Whether you're starting a new Nuxt project or looking to enhance an existing one, Nx offers a compelling set of tools and features to streamline your development process. From modularization to caching, the integration of Nx into your Nuxt projects promises a more efficient, scalable, and enjoyable development experience. By embracing Nx's capabilities in your Nuxt development, you're not just optimizing your current workflow; you're future-proofing your development process. As your projects grow and evolve, Nx's modular architecture and powerful tooling will continue to provide value, making your development experience more enjoyable and productive.
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X / Twitter](https://twitter.com/nxdevtools) - [LinkedIn](https://www.linkedin.com/company/nrwl)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Community Discord](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app)
diff --git a/docs/blog/2024-02-07-fast-effortless-ci.md b/docs/blog/2024-02-07-fast-effortless-ci.md
new file mode 100644
index 0000000000..a3b858b438
--- /dev/null
+++ b/docs/blog/2024-02-07-fast-effortless-ci.md
@@ -0,0 +1,126 @@
+---
+title: Fast, Effortless CI
+authors: [Isaac Mann]
+cover_image: '/blog/images/2024-02-07/featured_img.png'
+tags: [nx, nx-cloud, release]
+reposts: []
+---
+
+## From 90-minute to 10-minute CI Pipelines
+
+{% youtube src="https://www.youtube.com/embed/_FSHQIwITic?si=GaAz4B0nYUEzVftN" title="Fast, Effortless CI" /%}
+
+> TL;DR; Nx is releasing a new product called Nx Agents that dramatically improves the speed and maintainability of your CI pipeline.
+
+In 2014, the state of the art for running tests and builds in your repository were tools like Gulp and Grunt. They were good enough to get the job done, but they were fundamentally **low-level** build tools. That is, they did exactly what they were programmed to do and no more. That approach works well in a single project where the configuration does not change frequently, but becomes problematic in a monorepo environment where there are multiple applications and multiple teams working in the same repository.
+
+Nx was created in 2017 to address this problem. Nx is a build system that operates on a **higher level** where developers define the relationships between tasks and then Nx to decides the optimal way to run those tasks. In the same way, developers can define the inputs and outputs of tasks, then Nx automatically caches those task results. Developers tell Nx what a task does and then Nx can decide how best to run that task.
+
+With [Nx Agents](/ci/features/distribute-task-execution), Nx is applying this same mindset to the problem of slow and costly CI pipelines. Nx gives you both **Smart Monorepos** and **Fast CI**.
+
+## Why is CI So Hard?
+
+Just like build tools from the last decade, CI pipelines are defined in a low-level, machine-oriented way. Each step in the pipeline is defined explicitly. It is up to the CI developer to ensure that all pre-requisites are available for each new step in the pipeline. If tasks need to be run in parallel on multiple machines, all the assets needed by each of those tasks need to be copied over to those machines before the tasks are run. Then, if the task dependencies ever change, the CI pipeline configuration needs to be updated to account for those changes.
+
+The script below is a very simple example with only three tasks and one file being shared between them, but you can already see the complexity inherent in the system.
+
+```yaml
+jobs:
+  build_base:
+    steps:
+      - run: npm run build-base
+      - name: Save assets for use by other jobs
+        uses: actions/upload-artifact@v4
+        with:
+          name: base_output
+          path: base/output.ts
+
+  build_app1:
+    needs: build_base
+    steps:
+      - name: Download base output
+        uses: actions/download-artifact@v4
+        with:
+          name: base_output
+      - run: npm run build-app1
+
+  build_app2:
+    needs: build_base
+    steps:
+      - name: Download base output
+        uses: actions/download-artifact@v4
+        with:
+          name: base_output
+      - run: npm run build-app2
+```
+
+At any point in the future, if a task is added to the system or there is a change to the output files of build_base, this pipeline will need to be updated.
+
+## A Build System That Runs Your CI
+
+Part of the reason CI is so difficult to maintain is that it has no knowledge of your repository. Your CI provider can’t optimize your pipeline because it doesn’t even know the language you’re using, let alone relationships between your projects. A build system, on the other hand, must know all that information in order to properly function.
+
+The key that unlocks all the power of Nx Agents is this architectural shift:
+
+> Rather than the traditional approach where your CI provider invokes a build tool, the Nx build system will manage your CI pipeline.
+
+Nx already knows how your repository is structured and the best way to run tasks locally. Nx can use that exact same knowledge to run tasks in the best way on multiple machines in CI.
+
+## Distribute Tasks with Nx Agents
+
+When using Nx Agents, distributing tasks across multiple machines becomes as simple as running those tasks on your local machine. This is because any task artifacts will automatically be copied to the agent machines where they are needed.
+
+Instead of explicitly defining what order to run tasks, your CI pipeline only needs to tell Nx **what** needs to be accomplished and Nx will figure out **how** best to do it.
+
+![](/blog/images/2024-02-07/bodyimg1.webp)
+
+The pipeline configuration below will work no matter how many projects are in the repository or how complex the dependencies between those projects are.
+
+```yaml
+jobs:
+  main:
+    # Tell Nx Cloud how many agents to use and the name of the last task
+    - run: |
+        nx-cloud start-ci-run \
+          --distribute-on="3 linux-medium-js" \
+          --stop-agents-after="e2e-ci"
+    # Run tasks the same way you would locally
+    - run: nx affected -t lint test build --parallel=3
+    - run: nx affected -t e2e-ci --parallel=1
+```
+
+The only reason to modify this file is if you need to change the number of agent machines or there is another type of task that needs to run in CI.
+
+The `linux-medium-js` name in the CI configuration refers to a built-in launch template that Nx provides. If you can not find a template in [the default list](https://github.com/nrwl/nx-cloud-workflows/blob/main/launch-templates/linux.yaml) that meets your needs, you can provide your own. [With a single yaml file](/ci/features/distribute-task-execution#launch-templates), you can set up your agent environment in exactly the way you want with your own launch template.
+
+## Dynamically Allocate Agents
+
+Nx understands that some CI pipelines need more resources than others. To account for this, Nx Agents gives you the ability to [define three different classes of agent allocation configurations](/ci/features/dynamic-agents). You can use fewer agents for smaller PRs and more agents for larger PRs. This allows you to save money where possible and use the full power of Nx Agents when needed.
+
+![](/blog/images/2024-02-07/bodyimg2.webp)
+
+## Automatically Split E2E Tasks by File
+
+Typically, e2e tests are the tasks that take the longest in CI. In order to take advantage of parallelization and task distribution, these large tasks would need to be split into smaller tasks, but doing this manually would involve duplicating a lot of configuration code and making sure to keep that configuration synchronized. Nx 18’s [Project Crystal](/blog/2024-02-05-nx-18-project-crystal) allows you to [automatically create separate Cypress and Playwright tasks](/ci/features/split-e2e-tasks) for each spec file in the e2e project. These individual tasks can all be triggered by running the `e2e-ci` task. What was once a tedious manual process can now be done for you automatically.
+
+![](/blog/images/2024-02-07/bodyimg3.webp)
+
+## Identify and Re-run Flaky Tasks
+
+There are some tasks that will fail or succeed in CI without any changes to the task’s code. These are flaky tasks and in order to merge a change in unrelated code, developers need to manually re-run the entire pipeline until that flaky task succeeds. Because Nx is already tracking inputs and outputs of tasks, it knows when a task is flaky. Now, Nx Cloud will [automatically re-run a flaky task if it fails](/ci/features/flaky-tasks), without a developer needing to manually trigger it.
+
+![](/blog/images/2024-02-07/bodyimg4.webp)
+
+## Run Some Tasks on Another CI Provider
+
+If you have a task that can’t be run on Nx Agents for some reason, you can easily [flag it to run directly on the main CI job](/ci/reference/nx-cloud-cli#enablingdisabling-distribution). Add a `--no-agents` flag to the command and Nx will not run it on an agent.
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2024-02-09-versioning-and-releasing-packages.md b/docs/blog/2024-02-09-versioning-and-releasing-packages.md
new file mode 100644
index 0000000000..1354a720a1
--- /dev/null
+++ b/docs/blog/2024-02-09-versioning-and-releasing-packages.md
@@ -0,0 +1,321 @@
+---
+title: Versioning and Releasing Packages in a Monorepo
+authors: [Juri Strumpflohner]
+cover_image: '/blog/images/2024-02-09/featured_img.png'
+tags: [nx, nx-cloud, releases, changelog]
+---
+
+When it comes to publishing NPM packages, there are a bunch of libraries and utilities out there that help with the process. Many of them are tricky when it comes to properly configuring them in a monorepo.
+
+Nx already has all that knowledge, and it can leverage the information it has about your project dependencies and relationships to optimize your task runs.
+
+Here’s the structure of our current example workspace we’re going to refer to in this article:
+
+![@tuskdesign/demo relies on @tuskdesign/forms and @tuskdesign/buttons, and @tuskdesign/forms also depends on @tuskdesign/buttons](/blog/images/2024-02-09/bodyimg1.webp)
+
+As you can see `@tuskdesign/forms` relies on `@tuskdesign/buttons` and as such has to consider that when running versioning and publishing.
+
+> **Note:** it is worth mentioning that the Nx community has also stepped up in the past and created jscutlery/semver, a package that adds semantic versioning and publishing to your Nx workspace. Make sure to check that out as well.
+
+---
+
+**Prefer a video?**
+
+{% youtube src="https://www.youtube.com/embed/KjZKFGu3_9I?si=L-8oRzy-hV-WF_pS" title="Versioning and Releasing Packages in a Monorepo" /%}
+
+---
+
+## Table Of Contents
+
+- [Adding Nx](#adding-nx)
+- [Installing the JavaScript/TypeScript versioning Package](#installing-the-javascripttypescript-versioning-package)
+- [Running Nx Release](#running-nx-release)
+- [Excluding Packages](#excluding-packages)
+- [Running the Versioning and Changelog Generation](#running-the-versioning-and-changelog-generation)
+- [Versioning using Conventional Commits](#versioning-using-conventional-commits)
+- [Generating a GitHub Release](#generating-a-github-release)
+- [Programmatic Mode](#programmatic-mode)
+- [Wrapping Up](#wrapping-up)
+- [Learn more](#learn-more)
+
+## Adding Nx
+
+You can add Nx to your existing monorepo workspace using the following command:
+
+```shell
+pnpm dlx nx@latest init
+```
+
+(use `npx nx@latest init` in a NPM workspace)
+
+This brings up a couple of questions including whether to install [Project Crystal plugins](/blog/2024-02-05-nx-18-project-crystal).
+
+![](/blog/images/2024-02-09/bodyimg2.webp)
+
+It gives you some additional benefits ([you can read more here](/blog/2024-02-05-nx-18-project-crystal)), but you don’t have to as it is not required for Nx Release.
+
+## Installing the JavaScript/TypeScript versioning Package
+
+Nx Release is made to handle the versioning and publishing of any package. For now, the Nx team provides the JS/TS package publishing approach, which comes with the `@nx/js`. You could provide your own implementation, like for Cargo, NuGet etc.
+
+```shell
+pnpm add @nx/js -w
+```
+
+_(We use the `-w` flag to install it at the monorepo root level)_
+
+## Running Nx Release
+
+Once you’re set-up, you can already go ahead and run the following command:
+
+```shell
+pnpm nx release --dry-run
+```
+
+This command will do the versioning, changelog generation, and publishing steps together. Note the `--dry-run` simply simulating a run.
+
+![](/blog/images/2024-02-09/bodyimg3.webp)
+
+You’ll get asked whether you want to release a major, pre-major, minor… release or choose an exact version.
+
+Once this runs through, you might hit the following error:
+
+![Error message that reads: "> NX Unable to determine the previous git tag. If this is the first release of your workspace, use the --first-release option or set the "release.changelog.automaticFromRef" config property in nx.json to generate a changelog from the first commit. Otherwise, be sure to configure the "release. releaseTagPattern" property in nx.json to match the structure of your repository's git tags.](/blog/images/2024-02-09/bodyimg4.webp)
+
+Since Nx Release has never been run on this repository, it cannot figure out the historical information, for instance, to generate the changelog starting from previous git tags. Re-run the command with `--first-release`
+
+```shell
+pnpm nx release --dry-run --first-release
+```
+
+If you inspect the console output, you can see that:
+
+- it would increment the version in the package.json
+- update the pnpm (or npm) lockfile
+- stage the changes with git
+- creates a `CHANGELOG.md` file
+- git commits everything
+- git tags the commit using the version
+
+The dry-run mode also nicely previews all `package.json` changes in a git diff style:
+
+![](/blog/images/2024-02-09/bodyimg5.png)
+
+Note, if you want to get even more insights into what is happening when running the command, you can use the `--verbose`, which will also print the actual git commands.
+
+## Excluding Packages
+
+If you look closely at the dry-run logs, you may notice that Nx Release bumped the version on all of our packages:
+
+- `@tuskdesign/forms`
+- `@tuskdesign/buttons`
+- `@tuskdesign/demo`
+
+![](/blog/images/2024-02-09/bodyimg6.png)
+
+While we want to have it bumped on the `forms` and `buttons` packages, the `demo` is just for us to test things in the workspace. In this particular workspace, Nx Release doesn't have a way to distinguish what is an app and what is a library/package. Note, if you're in an Nx-generated workspace that uses Nx Plugins, you'd potentially have that classification in the `project.json` files.
+
+In our particular scenario, let's exclude `@tuskdesign/demo` as follows:
+
+```json {% fileName="nx.json" %}
+{
+    ...
+    "release": {
+        "projects": ["*", "!@tuskdesign/demo"]
+    }
+}
+```
+
+You can also explicitly list the packages to be released individually. Or, as shown above, include all (`*`) and exclude the private package.
+
+If you re-run the `nx release` command, you'll see that `@tuskdesign/demo` will be ignored now.
+
+## Running the Versioning and Changelog Generation
+
+Once you have configured the excluded packages, feel free to go ahead and run the command without `--dry-run:`
+
+```
+pnpm nx release --first-release
+```
+
+You can skip the release part when prompted for now. Check how the workspace got updated, incrementing the `package.json` version property and updating the version on the package dependency definition, i.e. the `@tuskdesign/buttons` version got updated in the `@tuskdesign/forms` package.json.
+
+## Versioning using Conventional Commits
+
+Instead of manually confirming the next version each time, we can use a versioning strategy: [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) is a commonly adopted approach for publishing packages.
+
+To configure conventional commits with Nx Release, go to the `nx.json` and adjust it as follows:
+
+```json {% fileName="nx.json" %}
+{
+    ...
+    "release": {
+        "projects": ["*", "!@tuskdesign/demo"],
+        "version": {
+            "conventionalCommits": true
+        }
+    }
+}
+```
+
+If you now run...
+
+```shell
+pnpm nx release --dry-run
+```
+
+... you'll notice that it doesn't pick up any changes because it leverages conventional commit, and we haven't changed anything yet.
+
+![](/blog/images/2024-02-09/bodyimg7.webp)
+
+Let’s go ahead and change something in our `@tuskdesign/buttons` package and then commit it as follows:
+
+```shell
+git commit -am 'feat(buttons): add new background shadow'
+```
+
+Now re-run the `nx release command` (don't forget the `--dry-run`). You'll see how it chooses `v1.2.0` as our new version (we had `v1.1.0` previously), given we added a new feature (denoted by the `feat(...)` conventional commit).
+
+![](/blog/images/2024-02-09/bodyimg8.webp)
+
+It also generates a nice `CHANGELOG.md` for us:
+
+```shell
+## 1.2.0 (2024-02-09)
+
+### 🚀 Features
+
+- **buttons:** add new background shadow
+
+### ❤️  Thank You
+
+- Juri
+
+## 1.1.0 (2024-02-09)
+
+This was a version bump only, there were no code changes.
+```
+
+## Generating a GitHub Release
+
+Instead of just generating a `CHANGELOG.md` entry in our repository you can also opt-in for creating a Github release (here's the example of the [Nx repository](https://github.com/nrwl/nx/releases)).
+
+```json {% fileName="nx.json" %}
+Use the `createRelease` property and set it to `github`.
+{
+    ...
+    "release": {
+        "projects": ["*", "!@tuskdesign/demo"],
+        "version": {
+            "conventionalCommits": true
+        },
+        "changelog": {
+            "workspaceChangelog": {
+                "createRelease": "github"
+            }
+        }
+    }
+}
+```
+
+To see the working, you need to make sure to:
+
+- push the repo to GitHub
+- make some change so you can run the `nx release` command again and get a changelog generated
+- now also get a GH release created
+
+Note, you can still use `--dry-run` and it'd show you the URL where the GitHub release would be created. You can also use the `--skip-publish` to skip the NPM publishing.
+
+## Programmatic Mode
+
+As you’ve seen, you can use `nx release` right away with minimal configuration. However, we are very well aware that many real-world scenarios are more complex, you want/need more control over when the version is happening, when the changelog generation kicks in and so on. This is why we also introduced a **programmatic API.**
+
+This approach gives you full control to embed Nx Release into your current release flow. There’s a nice [example script in our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release) that can help you get started.
+
+Create a file — I call it `release.ts` - at the root of my workspace. Nx Release obviously doesn't care how the file is called or where you place it. You can also go with plain JS.
+
+Here’s the [example script from our docs](/features/manage-releases#using-the-programmatic-api-for-nx-release):
+
+```ts
+import { releaseChangelog, releasePublish, releaseVersion } from 'nx/release';
+import * as yargs from 'yargs';
+
+(async () => {
+  const options = await yargs
+    .version(false) // don't use the default meaning of version in yargs
+    .option('version', {
+      description:
+        'Explicit version specifier to use, if overriding conventional commits',
+      type: 'string',
+    })
+    .option('dryRun', {
+      alias: 'd',
+      description:
+        'Whether or not to perform a dry-run of the release process, defaults to true',
+      type: 'boolean',
+      default: true,
+    })
+    .option('verbose', {
+      description:
+        'Whether or not to enable verbose logging, defaults to false',
+      type: 'boolean',
+      default: false,
+    })
+    .parseAsync();
+
+  const { workspaceVersion, projectsVersionData } = await releaseVersion({
+    specifier: options.version,
+    dryRun: options.dryRun,
+    verbose: options.verbose,
+  });
+
+  await releaseChangelog({
+    versionData: projectsVersionData,
+    version: workspaceVersion,
+    dryRun: options.dryRun,
+    verbose: options.verbose,
+  });
+
+  // The returned number value from releasePublish will be zero if all projects are published successfully, non-zero if not
+  const publishStatus = await releasePublish({
+    dryRun: options.dryRun,
+    verbose: options.verbose,
+  });
+  process.exit(publishStatus);
+})();
+```
+
+You can invoke it with [tsx](https://github.com/privatenumber/tsx) or [tsnode](https://www.npmjs.com/package/ts-node).
+
+```
+pnpm dlx tsx release.ts
+```
+
+Notice by default in the script we have `dry-run` enabled as a more cautious approach to not accidentally publish something as we keep editing and trying our programmatic setup.
+
+From here on you have full control and can pretty much do whatever works best for your workspace setup. Common examples include:
+
+- moving files to a common root-level `dist/` folder and version and release them from there. This is pretty common to avoid messing with your src files and swapping versions there, allowing you to always depend on the latest local packages for instance.
+- setting up fully automated releases on CI, including enabling provenance support. Our docs have [more details on how to set that up](/recipes/nx-release/publish-in-ci-cd) or check out the linked talk above which goes through those steps.
+
+## Wrapping Up
+
+With this release of Nx Release it is fully ready to be used. Make sure to check out our docs on [Managing Releases](/features/manage-releases) as well as our [release-related recipes](/recipes/nx-release).
+
+Here are some example repositories already leveraging Nx release:
+
+- [Our own Nx Repo](https://github.com/nrwl/nx/blob/master/scripts/nx-release.ts)
+- [RxJS repo](https://github.com/ReactiveX/rxjs/tree/master/scripts)
+- [Typescript-eslint](https://github.com/typescript-eslint/typescript-eslint/blob/main/tools/release/release.mts)
+- [Watch the live stream](https://www.youtube.com/watch?v=lYNa6Ct4RkY) with [Kent](https://twitter.com/kentcdodds) and [James](https://twitter.com/MrJamesHenry) as they enable Nx Release on the [EpicWeb workshop app repository](https://github.com/epicweb-dev/kcdshop)
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X / Twitter](https://twitter.com/nxdevtools) — [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](https://go.nx.dev/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2024-02-15-launch-week-recap.md b/docs/blog/2024-02-15-launch-week-recap.md
new file mode 100644
index 0000000000..7ac61a948e
--- /dev/null
+++ b/docs/blog/2024-02-15-launch-week-recap.md
@@ -0,0 +1,147 @@
+---
+title: Launch Nx Week Recap
+authors: [Zack DeRose]
+cover_image: '/blog/images/2024-02-15/featured_img.png'
+tags: [nx, nx-cloud, releases, changelog]
+---
+
+We just finished wrapping up [Launch Nx Week](/launch-nx), which ran from February 5–9, including a full conference on Thursday!
+
+In this article, we’re going to recap all the things launched during Launch Nx Conf, as well as all the talks given during the conference! Here’s a set of links so you can fast-forward to the stuff you’re most interested in if you want!
+
+**Prefer a video?**
+
+{% youtube src="https://www.youtube.com/embed/Ed1ZCNqWF1Q?si=m8LRyeJy_ZbCODJP" title="Launch Nx Week Recap" /%}
+
+---
+
+- [Nx 18.0 && Project Crystal](#nx-180-project-crystal)
+  - [Project Crystal — By Juri Strumpflohner](#conference-talk-project-crystal)
+  - [Project Crystal + .NET in Action — By Craigory Coppola](#conference-talk-project-crystal-net-in-action)
+- [New Plugin: @nx/nuxt](#new-plugin-nxnuxt)
+- [Nx Agents](#nx-agents-launched)
+  - [Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos — By Rares Matei](#conference-talk-nx-agents-walkthrough-effortlessly-fast-ci-built-for-monorepos)
+  - [Solving E2E Tests — By Altan Stalker](#conference-talk-solving-e2e-tests)
+- [Tusky](#tusky)
+- [Nx Release](#nx-release-is-stable)
+  - [Releasing Nx Release — By James Henry](#conference-talk-releasing-nx-release)
+
+## Nx 18.0 && Project Crystal
+
+Exciting news!! We’ve broken our standard release cadence of publishing a new major version every 6 months to release Nx 18, just 3 months after releasing Nx 17 in December 2024.
+
+Juri announced launched Project Crystal with this video:
+
+{% youtube src="https://www.youtube.com/embed/Ed1ZCNqWF1Q?si=m8LRyeJy_ZbCODJP" title="Nx Project Crystal" /%}
+
+The short version is: Nx project crystal means Nx plugins make your codebases work more seemlessly with less config.
+
+For the long version, checkout this blog post by Juri where he describes [how Nx plugins are now more like VsCode Extentions](/blog/2024-02-05-nx-18-project-crystal)!
+
+And don’t miss our two conference talks on this subject:
+
+### Conference Talk: Project Crystal
+
+**Speaker:** [Juri Strumpflohner](https://twitter.com/juristr) | [slides](https://drive.google.com/file/d/1q6M0drdssU7Zb-4Y_f99fuupuOl1KYQN/view)
+
+{% youtube src="https://www.youtube.com/embed/PzCgpM7qtTU?si=U5aEC7XjeS1NeKbT" title="Juri Conference Talk Project Crystal" /%}
+
+### Conference Talk: Project Crystal + .NET in Action
+
+**Speaker:** [Craigory Coppola](https://twitter.com/enderagent) | [slides](https://docs.google.com/presentation/d/1uveIe6HB7xwSkh7FBGZfF8Unh5YZzm5X/edit?usp=sharing&ouid=109667724870581513512&rtpof=true&sd=true) | [example repo](https://github.com/AgentEnder/nx-launch-conf-demos)
+
+{% youtube src="https://www.youtube.com/embed/fh-yzOuQGE8?si=a-XRXJfaBCerz3i-" title="Craigory Conference Talk Project Crystal + .Net" /%}
+
+## New Plugin: @nx/nuxt
+
+On Tuesday we launched our newest plugin, and our first plugin to be :gem:crystalized:gem: from it’s very beginning: @nx/nuxt!
+
+Zack explains Nuxt and how to use the new plugin in this video:
+
+{% youtube src="https://www.youtube.com/embed/1L-bDvEemoc?si=wHQvuTDfXFs3vjaC" title="Zack explaining new plugin @nx/nuxt" /%}
+
+To add @nx/nuxt to your codebase, use the command:
+
+```shell
+> nx add @nx/nuxt
+```
+
+Huge thanks to [Katerina](https://twitter.com/psybercity) for her work on the plugin, and Nuxt maintainer, [Daniel Roe](https://twitter.com/danielcroe), for helping to guide the project!
+
+Zack, Katerina, and Daniel got together to live code a working tic-tac-toe app using the new Nuxt plugin and [partykit](https://www.partykit.io/) in this livestream:
+
+{% youtube src="https://www.youtube.com/embed/uHwUxFYX2DY?si=lyYg3XPIx688k8HY" title="@nx/nuxt with Nuxt maintainer, Daniel Roe!" /%}
+
+## Nx Agents Launched
+
+Nx Agents are here!! We launched Nx Agents on Wednesday, and it climbed into the top 20 on [Product Hunt](https://www.producthunt.com/products/nx-cloud#nx-agents)!
+
+We’re very excited about Nx Agents because we think that in its current state, Continuous Integration/Deployment is broken, and we think that Nx paired with Nx Agents fixes Continuous Integration. Zack explains more in this video:
+
+{% youtube src="https://www.youtube.com/embed/_FSHQIwITic?si=jDpwTVXLYFXiHEm0" title="Nx Agents" /%}
+
+Be sure to also checkout the [blog post from Isaac on Nx Agents](/blog/2024-02-07-fast-effortless-ci), including explanations of exclusive features like auto-detection and retrying for flaky tasks and automatically splitting lengthy end-to-end tests!
+
+You can [signup for Nx Agents NOW](https://nx.app/products/agents#content), and find out [more of the details in our docs](/ci/features/distribute-task-execution)!
+
+Rares and Altan are on the team building Nx Cloud, and during the conference, they dove deeper into some of these topics:
+
+### Conference Talk: Nx Agents Walkthrough: Effortlessly Fast CI Built for Monorepos
+
+**Speaker:** [Rares Matei](https://twitter.com/__rares) | [slides](https://drive.google.com/file/d/1k-cGCJUMP4axcCWoeih8n3dvo1oO_i_X/view?usp=sharing) | [example repo](https://github.com/rarmatei/shops-workflows/pulls) | [failed runs example](https://cloud.nx.app/cipes/65b27cf6d3ef5934decad746?utm_source=pull-request&utm_medium=comment) | [nx agents full run](https://cloud.nx.app/cipes/65b38179d3ef5934dede74c2?utm_source=pull-request&utm_medium=comment)
+
+{% youtube src="https://www.youtube.com/embed/XS-exYYP_Gg?si=skZTGYPEVJG7BrYZ" title="Nx Agents Walkthrough" /%}
+
+### Conference Talk: Solving E2E Tests
+
+**Speaker:** [Altan Stalker](https://twitter.com/StalkAltan)
+
+{% youtube src="https://www.youtube.com/embed/EO_tGa0Nx1s?si=3AvGaJkJaCeEjz1r" title="Solving E2E Tests" /%}
+
+## Tusky
+
+Thursday, we had a surprise announcement for our newest product on Nx Cloud: Tusky.
+
+{% youtube src="https://www.youtube.com/embed/Xfvv09wSoM8?si=jnzyLHtdWBLwx_U0" title="Tusky" /%}
+
+Tusky is an Artificial Intelligence for your codebase, and it will be available on Nx Cloud soon — starting in Spring of 2024.
+
+In the teaser video, you can see some ways Tusky will be integrated into Nx Cloud to provide explainations on failed tasks, or cache misses.
+
+The more exciting features of Tusky though includes the ability to perfectly optimize the number of agents used per PR — even spinning up and tearing down agents mid-pipeline! This is a huge optimization for task distribution, and will help optimize both walltime of your CI, as well as compute costs!
+
+Tusky will also be able to provide organizational-level insights to your codebase, including automatically detecting development groups (like lines of business) inside your codebase based on commit history, and providing statistical insights on their commit patterns. We’re also excited about Tusky being able to make suggestions on things you can do to further optimize your codebase — like generating a PR to introduce [Codeowners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) to the repo!
+
+## Nx Release Is Stable
+
+Versioning and publishing packages is always a bit tricky. Mix in the added complexity of having multiple packages — sometimes with different versioning or publishing strategies — inside the same codebase, and things can get weird quick!
+
+For a long time, Nx has been purposefully versioning and publishing agnostic, but given our time spent as [stewards of Lerna](https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9) (the OG Javascript monorepo tool), we’ve been able to take alot of that experience and finally feel confident creating our own versioning and publishing implementation.
+
+Therefore, we’ve been working on a new command to the Nx CLI: [nx release](/recipes/nx-release/get-started-with-nx-release#get-started-with-nx-release). We launched this on Friday of our Launch Nx week!
+
+Juri goes into [full details in this blog post](/blog/2024-02-09-versioning-and-releasing-packages), and James Henry — our Director of Engineering and the primary engineer responsible for both maintaining Lerna and creating Nx Release — expands further in his conference talk:
+
+### Conference Talk: Releasing Nx Release
+
+**Speaker:** [James Henry](https://twitter.com/MrJamesHenry) | [example repo](https://github.com/JamesHenry/nx-release-cmd)
+
+{% youtube src="https://www.youtube.com/embed/KjZKFGu3_9I?si=83DjaHhpBSP7NP4n" title="Releasing Nx Release" /%}
+
+## Wrapping up
+
+Juri, Zack, and Victor wrapped up the week with a livestream recapping the launches from the week — including answering your questions live:
+
+{% youtube src="https://www.youtube.com/embed/xjLrFvEcxZw?si=O70JD4NgseP0lknA" title="Launch Nx Week Wrap Up" /%}
+
+That’s all for now folks! We’re just starting up a new iteration of development on Nx, so be sure to subscribe to [our YouTube channel](https://www.youtube.com/@nxdevtools) to get updates when new features land! Until next time, KEEP WORKING HARD!
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/2024-03-20-why-speed-matters.md b/docs/blog/2024-03-20-why-speed-matters.md
new file mode 100644
index 0000000000..d2cf326674
--- /dev/null
+++ b/docs/blog/2024-03-20-why-speed-matters.md
@@ -0,0 +1,104 @@
+---
+title: Monorepos - Why Speed Matters
+authors: ['Katerina Skroumpelou']
+tags: nx, nxdevtools, speed, ci
+cover_image: '/blog/images/2024-03-20/featured_img.png'
+---
+
+In the ever-evolving landscape of software development, efficiency and speed are vital. As projects grow in complexity, developers and teams need tools that can keep up without sacrificing quality or performance.
+
+Nx is a suite of powerful tools designed to optimize your development workflow, which sets the [building blocks for a fast CI](/ci/concepts/building-blocks-fast-ci). Nx is always innovating in many ways to make developers’ lives easier, but this post is exclusively focused on the things Nx has done in the past year to make development faster and faster.
+
+## Why speed matters
+
+The ability to iterate quickly and efficiently is vital for any software project. Speed in the development process offers several critical advantages:
+
+- **Faster feedback loops:** Quick iterations mean immediate feedback, allowing teams to adapt, learn, and improve their work on the fly.
+- **Reduced time to market:** Accelerating the development process can significantly cut down the overall time to market, providing a competitive edge which reclaims revenue that would have otherwise been lost.
+- **Decreased developer frustration:** [No more waiting for builds and tests to complete](/ci/concepts/reduce-waste). A streamlined workflow keeps morale high and productivity higher.
+
+If you’re using Nx already, you’re already familiar with
+
+- [**Affected**](/ci/features/affected) - identifying and running tasks only on projects impacted by code changes,
+- [**Nx Replay**](/ci/features/remote-cache) - our powerful cache and
+- [**Nx Agents**](/ci/features/distribute-task-execution) - the concept of [Parallelization and Distribution](/ci/concepts/parallelization-distribution).
+
+But let’s see all the extra things we did this past year to make everything faster.
+
+## Speed at the core
+
+### Rustifying Nx
+
+The Nx daemon has seen significant enhancements, notably through the use of Rust to calculate file hashes behind the scenes. This improvement not only speeds up the start-up times but also optimizes performance even without the daemon, especially on CI environments where the daemon isn't used. The benchmark results at [this repo](https://github.com/vsavkin/large-monorepo) showcase the remarkable speed improvements, making Nx competitive with native code solutions while maintaining the accessibility and flexibility of Node.js. Nx is still Node-first, so contributions are easier and only the most performance-critical parts of Nx are native code.
+
+### **Task Hasher and archive file innovations**
+
+The introduction of a task hasher written in Rust, alongside the use of an archive file to store workspace file hashes (`.nx/cache`), has significantly reduced the need for repetitive file system accesses. This innovation means that running multiple Nx commands in CI is much faster, as file hashing becomes unnecessary after the initial run.
+
+**The Archive file**
+
+The archive file is a binary file that contains the workspace file hashes with their last modified time. Every time Nx starts (ie, running `nx run project:target`) it gets all the files with their last modified time, and compares it to the archive. If the file exists in the archive, then Nx does not access the file system to read the file to hash (reading individual files is slower than just getting a list of files from a directory). So running multiple nx commands in CI is quick to start because Nx does not need to constantly hash files.
+
+### Nx Replay
+
+![](/blog/images/2024-03-20/bodyimg1.webp)
+
+Nx Replay enables caching and reusing of task results. It’s our well known Nx remote cache! It allows developers to avoid re-running expensive tasks by retrieving the cached results from a remote cache. This significantly improves build and test performance, as well as developer productivity. Nx Replay is also critical to the functioning of Nx Agents, which rely on the remote cache to ensure that the results of a task will be shared with every agent that needs them. By using Nx Replay, developers can optimize their workflows and reduce the time spent waiting for tasks to complete.
+
+With Nx Replay, you can see significant speed improvements in your CI pipelines for modified PRs. What’s also important is that if a task has been executed in CI, a developer running that same task locally can reuse the task result instead of actually running the task. So you will also see improvements locally.
+
+### **Nx Agents**
+
+![](/blog/images/2024-03-20/bodyimg2.avif)
+
+[Nx Agents](/ci/features/distribute-task-execution) represent the pinnacle of task distribution optimization, ensuring that tasks are executed as efficiently as possible based on the specific requirements of each change. Some features that make up this effort are:
+
+- [Easy integration with existing providers](/ci/features/distribute-task-execution#cicd-guides)
+  - Distribution is handled on the Nx Cloud infrastructure and all you need is a single line. What’s more, all results are played back to your original CI provider script which triggers the Nx Cloud distribution, so that you can make use of the resulting artifacts
+- [Efficient task distribution](/ci/features/dynamic-agents)
+  - Save compute resources and reduce costs, minimizing idle time and compute waste
+  - Dynamic sizing based on PR size
+- [Tusky](https://nx.app/products/tusky) - our AI solution - coming soon
+  - You set your desired cost/speed ratio, and you forget about any more configuration. We ensure maximum speed up to limits you set yourself.
+
+You can read more about Nx Agents [here](https://nx.app/products/agents#content).
+
+### **Atomizer**
+
+The [Atomizer](/ci/features/split-e2e-tasks) splits your Cypress or Playwright e2e tests by file. This significantly enhances granularity for caching, parallel execution, and flaky test identification. This granular approach ensures that individual test results can be cached and only the necessary tests rerun, greatly reducing CI pipeline times and facilitating more accurate flaky test detection.
+
+{% youtube src="https://www.youtube.com/watch?v=0YxcxIR7QU0" /%}
+
+### **Addressing flaky tests with test deflaking**
+
+Flaky tests can be a significant bottleneck in the CI process. Nx tackles this issue head-on by intelligently [re-running only the flaky tasks](/ci/features/flaky-tasks), rather than the entire pipeline. This approach not only saves time but also provides developers with more confidence in their CI pipeline's reliability.
+
+![](/blog/images/2024-03-20/bodyimg3.avif)
+
+Nx creates a hash of all the inputs for a task whenever it is run. If it encounters a task that fails with a particular set of inputs and then succeeds with those same inputs, Nx knows for a fact that the task is flaky.
+
+## New Nx features that tie in with our core speed improvements
+
+### Module Federation
+
+With the help of Nx and the Module Federation setup that Nx offers, you can split up large Angular apps into smaller “vertical slices”. This can significantly speed up your builds and app startup time. Nx has revolutionized the use of Module Federation, especially in how static remotes are built and served. We make use of Nx’s task orchestration, allowing users to fine tune the number of builds happening in parallel to improve local startup time, manage machine resources better, allow for scaling.
+
+### First-Class Playwright support
+
+With first-class support for Playwright through **`@nx/playwright`**, Nx offers out-of-the-box generators to run Playwright tests efficiently. This integration is especially powerful with features like Atomizer, enhancing the testing process's speed and reliability.
+
+## Conclusion
+
+Nx provides an unparalleled toolkit for developers and teams looking to optimize their development workflows, and we keep making it faster. By intelligently leveraging modern technologies and innovative optimizations, Nx delivers speed, efficiency, and reliability, allowing teams to focus on what matters most: building great software.
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X / Twitter](https://twitter.com/nxdevtools)
+- [LinkedIn](https://www.linkedin.com/company/nrwl)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Community Discord](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app)
diff --git a/docs/blog/2024-03-21-reliable-ci.md b/docs/blog/2024-03-21-reliable-ci.md
new file mode 100644
index 0000000000..3b9ae74cbd
--- /dev/null
+++ b/docs/blog/2024-03-21-reliable-ci.md
@@ -0,0 +1,176 @@
+---
+title: Reliable CI. A new execution model fixing both flakiness and slowness
+authors: [Victor Savkin]
+cover_image: '/blog/images/2024-03-21/featured_img.png'
+tags: [nx, nx-cloud, releases]
+---
+
+The proverbial slow and flaky CI isn’t the failure of the developers or even the testing tools. It’s the failure of the CI execution model we relied on for the last 20 years.
+
+**By switching from the old CI model, implemented as a graph of VMs, to the new one, implemented as a graph of tasks, we can solve both the flakiness and slowness.**
+
+In this blog post I’ll explore why this is the case, and how you can do it by using Nx Cloud.
+
+---
+
+## History of CI
+
+It’s easy to forget that Continuous Integration has been around for only 20 years. For reference, UI frameworks have been around since the 1970s.
+
+![](/blog/images/2024-03-21/bodyimg1.webp)
+
+The innovation in the CI space has been primarily in where the CI process is described and how the configuration is written. How the CI actually works has largely remained the same.
+
+## How CI works
+
+A traditional CI execution is a directed acyclic graph (DAG) of virtual machines (VMs). Each VM (often called a job) installs dependencies, restores NPM cache, and then runs the necessary steps to verify that, say, some tests pass.
+
+![](/blog/images/2024-03-21/bodyimg2.webp)
+
+**This CI execution is a distributed process, and a poorly designed one. It works reasonably well only when the number of jobs/VMs is very small and falls apart when the number gets larger.**
+
+---
+
+## Why does the current system not work?
+
+**Every distributed system needs efficient communication between nodes and the ability to tolerate failure.**
+
+The traditional CI execution model offers **very basic** means of communication: the status code propagation and ad-hoc ways of uploading/downloading files. Because the communication is effortful, in practice, **it’s either not done at all or very minimally.**
+
+To understand why the traditional CI execution model fails to handle failures, let’s review the types of failures we can have.
+
+Failures can be:
+
+- hard _(npm fails to install, nothing can run)_
+- soft _(a test takes a lot longer than it should because, perhaps, due to an out-of-memory issue)_
+
+Focusing on the latter is just as important as focusing on the former. **Slow CI is broken CI.**
+
+Tasks can fail:
+
+- legitimately _(a broken build)_
+- for external reasons _(npm install fails cause npm is down)_
+- for unknown reasons _(a flaky test)_
+
+**The traditional CI execution model doesn’t tolerate any of these failures.**
+
+## Problem in numbers
+
+Let’s see how varying a few parameters affects the probability of the CI execution failing.
+
+| Number of VMS | Avg Tests per VM | Flaky Test Probability | Slow Test Probability | Broken CI Builds (Flaky) | Slow CI Builds |
+| ------------- | ---------------- | ---------------------- | --------------------- | ------------------------ | -------------- |
+| 5             | 10               | 0.1%                   | 0.3%                  | 5%                       | 15%            |
+| 10            | 10               | 0.1%                   | 0.3%                  | 10%                      | 26%            |
+| 50            | 10               | 0.1%                   | 0.3%                  | 39%                      | 78%            |
+| 5             | 10               | 0.5%                   | 1%                    | 23%                      | 41%            |
+| 10            | 10               | 0.5%                   | 1%                    | 40%                      | 65%            |
+| 50            | 10               | 0.5%                   | 1%                    | 92%                      | 99%            |
+
+**The result is much worse than most intuitively expect.** For instance, assuming that an **e2e test has 1 in 1000 chance (0.1%) of failing** for a flaky reason, when the number of e2e tests reaches 500, **the probability of the CI failing for a flaky reason reaches 39%**, and the vast majority of CI executions are slowed down. Note, this is an exceptionally stable test suite. The bottom part of the table is more representative of a typical e2e suite, and the CI becomes “broken” at a much smaller scale.
+
+One can try to fix it by increasing the robustness of the tests, but at some point, doing this is costly. If an e2e test has a 10% chance of a flaky failure, it’s relatively easy to bring this number to 1%. Going from 1% to 0.5% is harder. Going from 0.5% to 0.1% is exceptionally hard and may be practically impossible. Testing complex systems is simply a difficult task.
+
+This is the formula for the failed CI run:
+
+![100 * (1 - chanceThatTestRunsWithoutFlakes ^ (avgTestsPerVm * numberOfVms))](/blog/images/2024-03-21/bodyimg3.webp)
+
+**As you can see, as the number of tests grows, the exponent will make more and more CI executions fail for flaky reasons. In this model, the only way to combat it is by increasing $chanceThatTestRunsWithoutFlakes$, but the more tests you have, the more challenging this becomes.** That's why a lot of projects move away from e2e tests or run them nightly (where they always fail).
+
+**It's not the team's fault. It's simply a losing battle with the current CI execution model.**
+
+We focused on the tests but the issue is more general.
+
+VMs sometimes fail to execute their setup steps (e.g., some package fails to install), and in this model it results in a failed CI execution.
+
+One of the setup steps can take a lot longer. Because the probabilities multiply, when the number of agents is high enough, this will happen frequently and will slow down a large number of CI executions. This is the formula for this case:
+
+![100 * (1 - chanceSetupIsFast ^ numberOfVms)](/blog/images/2024-03-21/bodyimg4.webp)
+
+For instance, with 50 agents, if there is a **1% chance that NPM install will take an extra 5 minutes, 40% of CI executions will be affected by it**, and your CI execution time goes from, say, **20m to 25m**. The slowness doesn't amortize across agents.
+
+---
+
+## Solution: Change the model
+
+**There is only that much gain to be had by optimizing the effectiveness and robustness of small units. Instead, we should focus on creating the systems we can use to achieve incredible performance and resilience with ordinary small units.**
+
+The CI model above has a fundamental problem: it is static. It defines a fixed number of VM, where each has a unique job to do. The VMs aren't interchangeable. If one of them fails or is slow, no other VM can help it.
+
+Nx Cloud introduces an entirely different model. Instead of the graph of VMs, the CI execution is expressed as a graph of tasks.
+
+By adding the following line…
+
+```shell
+npx nx-cloud start-ci-run --distribute-on="5 linux-medium-js"
+```
+
+... you are telling Nx Cloud to create five Nx Agents to execute all the tasks from all the commands that will follow.
+
+![](/blog/images/2024-03-21/bodyimg5.webp)
+
+**Nx Agents** are essentially VMs, but they are different from the ones in the traditional CI execution model.
+
+You can imagine the **traditional CI** model as a team where every member is given a **unique set of tasks.** If a team member gets sick, their work won't be completed, and the **CI execution will fail.** If a team member is slow, **no one can help them.** Everyone will just have to wait for them to complete their assignment.
+
+The **Nx Agent model** is a team where the **work doesn't get assigned ahead of time.** Instead, there is a pile of work in the middle of the room, and every **team member can take any piece of work** and do it. Once they are done with one piece of work, they can take another one. If a member gets sick, **a slightly smaller team can complete the job.** If a member is **slow**, the **other members will split the work.** In practice, it is even better than this. If an Nx Agent fails, another one will be started in its place.
+
+![](/blog/images/2024-03-21/bodyimg6.webp)
+
+## Solution in numbers
+
+Let's examine the two cases above.
+
+First, `npm install` **failing will not break the build.** Nx Cloud will simply spawn another Nx Agent in its place.
+
+The slowness of the `npm install` will affect the CI execution but in a very different way because it will be **amortized across agents.** So with 50 agents executing, adding 5 minutes to an `npm install` of one of the agents, will only increase the CI execution time by 6 seconds _(5 _ 60 / 50)\*.
+
+Second, **[Nx Cloud knows what specific tests are flaky](/ci/features/flaky-tasks), and if they fail, it will rerun them on a separate agent.** Rerunning them on a separate agent is crucial. Often flaky failures will continue to fail when rerun on the same agent.
+
+This is the formula:
+
+![chanceThatTestRunsWithoutFlakesUsingNx = 1 - (1 - chanceThatTestRunsWithoutFlakes) ^ numberOfTries](/blog/images/2024-03-21/bodyimg7.webp)
+
+If we examine the case above, where the test flaky happened 1 in 1000, two retries will result in _1 - (1–0.999)^3^ = 0.999999999_, which **brings the likelihood of the CI failing for a flaky reason to 0.000005%.**
+
+**The Nx Cloud model handles both hard and soft failures. Your agents can crush or be slow - doesn't matter. Your tests can fail or be slow - doesn't matter. Your CI will complete fast.**
+
+---
+
+## Can we fix the traditional model?
+
+It's possible to make the traditional CI model more reliable but the solution isn't adequate for large workspaces.
+
+For instance, in principle, it is possible to add retrying logic to every CI step. It's cumbersome and widely-used CI steps (e.g., popular Github Actions) don't do it. But even if you manage to wrap every step, this isn't bulletproof because many failures are unrecoverable.
+
+**Slow setup steps simply cannot be fixed or amortized.**
+
+One can add rerunning the same e2e test multiple times on the same machine to deal with flakes but there are numerous problems with this.
+
+**One of the most common reasons why e2e tests are flaky is because they create side effects.** For instance, they can create records in the db. They have some logic to clean it up, but it is imperfect. Or tests can assume that some fixture will be modified once. Ideally, this would never happen, but in practice it happens all the time. **Nx Cloud will always retry the same task on a different agent to avoid this problem.**
+
+**Don't forget, you actually need to know which tests are flaky. Most of your failures will be legitimate so rerunning all the tests will make you CI slow. And those reruns cannot be amortized.**
+
+There are other practical problems. If you have enough VMs, rebuilding the app under test on each of them becomes impractical, so you need to build it once and send it to all your VMs. Your e2e tests have to be partitioned into small units to allow for efficient distribution. And the list of problems goes on.
+
+**The traditional CI model is not really fixable because it makes no assumptions about its execution steps and, as a result, it cannot do anything automatically.**
+
+**The Nx Cloud model only works when your build system and CI are built for each other.** The CI needs to know the task graph, what a task requires, what files it creates. Without this information, nothing can be distributed, nothing can be rerun or deflaked. Nx and Nx Cloud (with Nx Agents) fit together. Nx can run tasks locally or can pass this metadata to Nx Cloud which will orchestrate the same computation across many VMs. Nx Cloud will move the right files to the right agents, split large e2e test suites, and deflake the tests automatically. This only works because of the assumptions made by the CI and the build tool.
+
+---
+
+## Performance
+
+The focus of this post is robustness. But the Nx Cloud model is also significantly faster and more efficient. Because Nx Agents are interchangeable, Nx Cloud will use a different number of agents depending on the size of the code change. It can split the work more effectively across agents, reduce the number of npm installs required, split large e2e suites into smaller units and more.
+
+## Summary
+
+The spirit of this post is similar to Alan Kay's quote, "A change of perspective is worth 80 IQ points". By changing the CI execution model, Nx Cloud makes some difficult, almost unsolvable, problems easy.
+
+---
+
+You can learn more about Nx Cloud on [nx.app](https://nx.app) and Nx open source on [nx.dev](https://nx.dev).
+
+**Nx Cloud Pro includes a 2-month free trial** that is definitely worth trying out if you're curious what Cloud Pro can do for your CI. You can try out Nx Agents, e2e test splitting, deflaking and more. [Learn more about Nx Cloud Pro.](https://nx.app/campaigns/pro)
+
+We also have a **Pro for Startups** plan which offers agents that are 3.5x cheaper than analogous VMs on CircleCI or Github Actions. [Learn more about Nx Pro for Startups.](https://nx.app/campaigns/pro-for-startups)
diff --git a/docs/blog/2024-04-19-manage-your-gradle.md b/docs/blog/2024-04-19-manage-your-gradle.md
new file mode 100644
index 0000000000..69a2944f2b
--- /dev/null
+++ b/docs/blog/2024-04-19-manage-your-gradle.md
@@ -0,0 +1,217 @@
+---
+title: Manage Your Gradle Project using Nx
+authors: ['Emily Xiong']
+cover_image: '/blog/images/2024-04-19/featured_img.png'
+tags: [nx, gradle, how-to]
+---
+
+Here’s my situation: I have a Gradle workspace with multiple Gradle libraries. How do I easily view the relationships between different libraries? I have a monorepo workspace with both Gradle and Javascript libraries, how do I manage these libraries of different tech stacks?
+
+We are very excited to announce our support for Gradle with our new plugin: `@nx/gradle`.
+
+The Nx Gradle plugin registers Gradle projects in your Nx workspace. It allows Gradle tasks to be run through Nx. Nx effortlessly makes your [CI faster](/ci/intro/ci-with-nx).
+
+> **Note:** this plugin is currently experimental.
+
+This blog will show you:
+
+- [What is Nx?](#what-is-nx)
+- [How to add Nx to a Gradle workspace](#how-to-add-nx-to-a-gradle-workspace)
+- [How to add @nx/gradle to an existing Nx workspace](#how-to-add-nxgradle-to-an-existing-nx-workspace)
+
+---
+
+## What is Nx?
+
+Before we start, let’s answer this question: what is Nx and why should we use it?
+
+From [nx.dev](https://nx.dev): “Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.” It sounds good, what benefits does it bring?
+
+Nx adds the following features to your workspace:
+
+- [Cache task results](/features/cache-task-results): By storing task outputs in a cache, subsequent runs can skip redundant computations and reuse previously calculated results, significantly speeding up build processes. Nx intelligently manages this caching mechanism, invalidating the cache automatically when relevant inputs change.
+- [Distribute task execution](/ci/features/distribute-task-execution): Nx CI efficiently distributes tasks across multiple machines for faster build times. It uses a distributed task execution algorithm to intelligently divide and assign tasks to available resources, minimizing redundant work and maximizing parallelism.
+- [Run only tasks affected by a PR](/ci/features/affected): Nx identifies changes made since a specified base commit or branch, and then selectively runs tasks (like tests, linting, or builds) related to those changes.
+- [Interactively explore your workspace](/features/explore-graph): Nx allows developers to visualize and understand the dependencies and relationships within their projects.
+
+![Example Nx Graph](/blog/images/2024-04-19/bodyimg1.webp)
+
+---
+
+## How to add Nx to a Gradle Workspace?
+
+Now we understand the benefits of Nx, now let’s set it up. The setup is pretty easy, just need to run one command.
+
+In the workspace, run the below command:
+
+```shell
+npx nx@latest init
+```
+
+In the terminal, it should output:
+
+```shell
+Setting Nx up installation in `.nx`. You can run Nx commands like: `./nx --help`
+CREATE nx.json
+UPDATE .gitignore
+CREATE .nx/nxw.js
+CREATE nx.bat
+CREATE nx
+
+ NX   Recommended Plugins:
+
+Add these Nx plugins to integrate with the tools used in your workspace.
+
+✔ Which plugins would you like to add? Press <Space> to select and <Enter> to submit. · @nx/gradle
+
+
+added 111 packages, and audited 112 packages in 2s
+
+21 packages are looking for funding
+  run `npm fund` for details
+
+found 0 vulnerabilities
+
+✔ Installing @nx/gradle@latest...
+✔ Initializing @nx/gradle...
+```
+
+That’s it! Now we have Nx in our Gradle project.
+
+### Example: Gradle Init
+
+If you create your Gradle workspace using gradle init, by running `npx nx@latest init`, you will get:
+
+![](/blog/images/2024-04-19/bodyimg2.webp)
+
+It adds a .nx folder in the workspace root and nx executable files. Now you can run commands using ./nx (or nx.bat for Windows machines).
+
+For example, you can run Gradle tasks using Nx now:
+
+```shell
+# macos/linux
+./nx <gradle task> <gradle project>
+
+# windows
+nx.bat <gradle task> <gradle project>
+```
+
+If you build your Gradle library using the command `./gradlew :app:build` or `gradlew.bat :app:build`, you can run `./nx build app` or `nx.bat build app` to build your Gradle library.
+
+Now you can an alternative way to run Gradle tasks, how can we leverage Nx?
+
+### Nx Graph
+
+To see the project graph, run the below command:
+
+```shell
+# macos/linux
+./nx graph
+
+# windows
+nx.bat graph
+```
+
+![](/blog/images/2024-04-19/bodyimg3.webp)
+
+### Run Only Tasks Affected by a PR
+
+As mentioned before, Nx enables the ability to run only the tasks affected by a specific PR by running the below command:
+
+```shell
+# macos/linux
+./nx affected -t <task>
+
+# windows
+nx.bat affected -t <task>
+```
+
+For example, when you run `nx affected -t build`, Nx uses your git information to determine the files you changed in your PR. Nx determines the list of projects in the workspace that can be affected by this change and only runs the build task against changed files.
+
+You can also visualize the affected projects highlighted using the [Nx graph](/features/explore-graph). Simply run:
+
+```shell
+# macos/linux
+./nx affected:graph
+
+# windows
+nx.bat affected:graph
+```
+
+### Nx Console
+
+Furthermore, instead of running the command in terminal, you can use the editor tool [Nx Console](/getting-started/editor-setup). Anything you can do with Nx, you can do with Nx Console.
+
+![Screencap of Nx Console UI](/blog/images/2024-04-19/bodyimg4.webp)
+
+To download:
+
+- [**Nx Console - Visual Studio Marketplace**](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)
+- [**Nx Console - IntelliJ IDEs Plugin | Marketplace**](https://plugins.jetbrains.com/plugin/21060-nx-console)
+
+---
+
+## How to add @nx/gradle to an existing Nx workspace?
+
+If you have an existing Nx workspace, to add `@nx/gradle`, just run:
+
+```shell
+npx nx add @nx/gradle
+```
+
+That is it, it will add `@nx/gradle` plugin to your Nx workspace.
+
+You can view inferred tasks for Gradle project in your workspace, open the [project details view](/features/explore-graph#explore-projects-in-your-workspace) in Nx Console or run `nx show project my-project --web` in the command line.
+
+For all the interred tasks, you can run using Nx instead of Gradle:
+
+```shell
+nx <gradle task> <gradle project> [options]
+```
+
+For example, if you run `./gradlew :app:build` or `gradlew.bat :app:build` using Gradle command, to run using Nx: `nx build app`.
+
+### How @nx/gradle Infers Tasks
+
+The `@nx/gradle` plugin will create an Nx project for each Gradle configuration file present. Any of the following files will be recognized as a Gradle configuration file:
+
+- `gradle.build`
+- `gradle.build.kts`
+
+### @nx/gradle Configuration
+
+The `@nx/gradle` is configured in the plugins array in `nx.json`:
+
+```json {% fileName="nx.json" %}
+{
+  "plugins": [
+    {
+      "plugin": "@nx/gradle",
+      "options": {
+        "testTargetName": "test",
+        "classesTargetName": "classes",
+        "buildTargetName": "build"
+      }
+    }
+  ]
+}
+```
+
+Once a Gradle configuration file has been identified, the targets are created with the name you specify under `testTargetName`, `classesTargetName`, or `buildTargetName` in the `nx.json` plugins array. The default names for the inferred targets are `test`, `classes`, and `build`.
+
+---
+
+## Summary
+
+Here is how to set up Nx with the Gradle workspace. Hopefully, this gives you a good insight into how to get started with Gradle with Nx. The plugin is currently experimental, you can submit GitHub issues: [https://github.com/nrwl/nx/issues](https://github.com/nrwl/nx/issues).
+
+---
+
+## Learn more
+
+- [Nx Docs](/getting-started/intro)
+- [X/Twitter](https://twitter.com/nxdevtools) -- [LinkedIn](https://www.linkedin.com/company/nrwl/)
+- [Nx GitHub](https://github.com/nrwl/nx)
+- [Nx Official Discord Server](/community)
+- [Nx Youtube Channel](https://www.youtube.com/@nxdevtools)
+- [Speed up your CI](https://nx.app/)
diff --git a/docs/blog/images/2023-08-15/bodyimg1.webp b/docs/blog/images/2023-08-15/bodyimg1.webp
new file mode 100644
index 0000000000..6f784d6504
Binary files /dev/null and b/docs/blog/images/2023-08-15/bodyimg1.webp differ
diff --git a/docs/blog/images/2023-08-15/bodyimg2.webp b/docs/blog/images/2023-08-15/bodyimg2.webp
new file mode 100644
index 0000000000..7b21557d5e
Binary files /dev/null and b/docs/blog/images/2023-08-15/bodyimg2.webp differ
diff --git a/docs/blog/images/2023-08-15/bodyimg3.webp b/docs/blog/images/2023-08-15/bodyimg3.webp
new file mode 100644
index 0000000000..56f6216388
Binary files /dev/null and b/docs/blog/images/2023-08-15/bodyimg3.webp differ
diff --git a/docs/blog/images/2023-08-15/bodyimg4.webp b/docs/blog/images/2023-08-15/bodyimg4.webp
new file mode 100644
index 0000000000..575dd85ca6
Binary files /dev/null and b/docs/blog/images/2023-08-15/bodyimg4.webp differ
diff --git a/docs/blog/images/2023-08-15/bodyimg5.webp b/docs/blog/images/2023-08-15/bodyimg5.webp
new file mode 100644
index 0000000000..a109efde3c
Binary files /dev/null and b/docs/blog/images/2023-08-15/bodyimg5.webp differ
diff --git a/docs/blog/images/2023-08-15/bodyimg6.webp b/docs/blog/images/2023-08-15/bodyimg6.webp
new file mode 100644
index 0000000000..abe90633f1
Binary files /dev/null and b/docs/blog/images/2023-08-15/bodyimg6.webp differ
diff --git a/docs/blog/images/2023-08-15/featured_img.png b/docs/blog/images/2023-08-15/featured_img.png
new file mode 100644
index 0000000000..1b2a8c73a2
Binary files /dev/null and b/docs/blog/images/2023-08-15/featured_img.png differ
diff --git a/docs/blog/images/2023-10-20/bodyimg1.webp b/docs/blog/images/2023-10-20/bodyimg1.webp
new file mode 100644
index 0000000000..9aa8a1734e
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg1.webp differ
diff --git a/docs/blog/images/2023-10-20/bodyimg2.gif b/docs/blog/images/2023-10-20/bodyimg2.gif
new file mode 100644
index 0000000000..fe2d524650
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg2.gif differ
diff --git a/docs/blog/images/2023-10-20/bodyimg3.gif b/docs/blog/images/2023-10-20/bodyimg3.gif
new file mode 100644
index 0000000000..0a33365b3e
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg3.gif differ
diff --git a/docs/blog/images/2023-10-20/bodyimg4.gif b/docs/blog/images/2023-10-20/bodyimg4.gif
new file mode 100644
index 0000000000..7ba34dbba7
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg4.gif differ
diff --git a/docs/blog/images/2023-10-20/bodyimg5.webp b/docs/blog/images/2023-10-20/bodyimg5.webp
new file mode 100644
index 0000000000..2ff5178b42
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg5.webp differ
diff --git a/docs/blog/images/2023-10-20/bodyimg6.webp b/docs/blog/images/2023-10-20/bodyimg6.webp
new file mode 100644
index 0000000000..598cbfe7e4
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg6.webp differ
diff --git a/docs/blog/images/2023-10-20/bodyimg7.webp b/docs/blog/images/2023-10-20/bodyimg7.webp
new file mode 100644
index 0000000000..2e9ff0f3c5
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg7.webp differ
diff --git a/docs/blog/images/2023-10-20/bodyimg8.webp b/docs/blog/images/2023-10-20/bodyimg8.webp
new file mode 100644
index 0000000000..5f6295960b
Binary files /dev/null and b/docs/blog/images/2023-10-20/bodyimg8.webp differ
diff --git a/docs/blog/images/2023-10-20/featured_img.png b/docs/blog/images/2023-10-20/featured_img.png
new file mode 100644
index 0000000000..f34a9ac0fd
Binary files /dev/null and b/docs/blog/images/2023-10-20/featured_img.png differ
diff --git a/docs/blog/images/2023-12-20/bodyimg1.webp b/docs/blog/images/2023-12-20/bodyimg1.webp
new file mode 100644
index 0000000000..a73affb708
Binary files /dev/null and b/docs/blog/images/2023-12-20/bodyimg1.webp differ
diff --git a/docs/blog/images/2023-12-20/bodyimg2.webp b/docs/blog/images/2023-12-20/bodyimg2.webp
new file mode 100644
index 0000000000..f1e1a17e5e
Binary files /dev/null and b/docs/blog/images/2023-12-20/bodyimg2.webp differ
diff --git a/docs/blog/images/2023-12-20/bodyimg3.webp b/docs/blog/images/2023-12-20/bodyimg3.webp
new file mode 100644
index 0000000000..48238ac0d8
Binary files /dev/null and b/docs/blog/images/2023-12-20/bodyimg3.webp differ
diff --git a/docs/blog/images/2023-12-20/bodyimg4.webp b/docs/blog/images/2023-12-20/bodyimg4.webp
new file mode 100644
index 0000000000..f5062357b9
Binary files /dev/null and b/docs/blog/images/2023-12-20/bodyimg4.webp differ
diff --git a/docs/blog/images/2023-12-20/bodyimg5.webp b/docs/blog/images/2023-12-20/bodyimg5.webp
new file mode 100644
index 0000000000..615fbc222a
Binary files /dev/null and b/docs/blog/images/2023-12-20/bodyimg5.webp differ
diff --git a/docs/blog/images/2023-12-20/featured_img.png b/docs/blog/images/2023-12-20/featured_img.png
new file mode 100644
index 0000000000..602599df98
Binary files /dev/null and b/docs/blog/images/2023-12-20/featured_img.png differ
diff --git a/docs/blog/images/2023-12-28/bodyimg1.webp b/docs/blog/images/2023-12-28/bodyimg1.webp
new file mode 100644
index 0000000000..76744f8742
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg1.webp differ
diff --git a/docs/blog/images/2023-12-28/bodyimg2.webp b/docs/blog/images/2023-12-28/bodyimg2.webp
new file mode 100644
index 0000000000..35ed553ad9
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg2.webp differ
diff --git a/docs/blog/images/2023-12-28/bodyimg3.gif b/docs/blog/images/2023-12-28/bodyimg3.gif
new file mode 100644
index 0000000000..fee976f125
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg3.gif differ
diff --git a/docs/blog/images/2023-12-28/bodyimg4.webp b/docs/blog/images/2023-12-28/bodyimg4.webp
new file mode 100644
index 0000000000..d1ef727f51
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg4.webp differ
diff --git a/docs/blog/images/2023-12-28/bodyimg5.webp b/docs/blog/images/2023-12-28/bodyimg5.webp
new file mode 100644
index 0000000000..a91ecfd429
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg5.webp differ
diff --git a/docs/blog/images/2023-12-28/bodyimg6.gif b/docs/blog/images/2023-12-28/bodyimg6.gif
new file mode 100644
index 0000000000..fe2d524650
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg6.gif differ
diff --git a/docs/blog/images/2023-12-28/bodyimg7.webp b/docs/blog/images/2023-12-28/bodyimg7.webp
new file mode 100644
index 0000000000..e5a41a577e
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg7.webp differ
diff --git a/docs/blog/images/2023-12-28/bodyimg8.webp b/docs/blog/images/2023-12-28/bodyimg8.webp
new file mode 100644
index 0000000000..63a3125f71
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg8.webp differ
diff --git a/docs/blog/images/2023-12-28/bodyimg9.webp b/docs/blog/images/2023-12-28/bodyimg9.webp
new file mode 100644
index 0000000000..9827140af2
Binary files /dev/null and b/docs/blog/images/2023-12-28/bodyimg9.webp differ
diff --git a/docs/blog/images/2023-12-28/featured_img.png b/docs/blog/images/2023-12-28/featured_img.png
new file mode 100644
index 0000000000..008ae3e7e1
Binary files /dev/null and b/docs/blog/images/2023-12-28/featured_img.png differ
diff --git a/docs/blog/images/2024-02-05/bodyimg1.webp b/docs/blog/images/2024-02-05/bodyimg1.webp
new file mode 100644
index 0000000000..90d1a02a2c
Binary files /dev/null and b/docs/blog/images/2024-02-05/bodyimg1.webp differ
diff --git a/docs/blog/images/2024-02-05/bodyimg2.webp b/docs/blog/images/2024-02-05/bodyimg2.webp
new file mode 100644
index 0000000000..f0a3d721f7
Binary files /dev/null and b/docs/blog/images/2024-02-05/bodyimg2.webp differ
diff --git a/docs/blog/images/2024-02-05/bodyimg3.webp b/docs/blog/images/2024-02-05/bodyimg3.webp
new file mode 100644
index 0000000000..6044564aed
Binary files /dev/null and b/docs/blog/images/2024-02-05/bodyimg3.webp differ
diff --git a/docs/blog/images/2024-02-05/bodyimg4.webp b/docs/blog/images/2024-02-05/bodyimg4.webp
new file mode 100644
index 0000000000..a4f56c940a
Binary files /dev/null and b/docs/blog/images/2024-02-05/bodyimg4.webp differ
diff --git a/docs/blog/images/2024-02-05/bodyimg5.webp b/docs/blog/images/2024-02-05/bodyimg5.webp
new file mode 100644
index 0000000000..a8f629c1ca
Binary files /dev/null and b/docs/blog/images/2024-02-05/bodyimg5.webp differ
diff --git a/docs/blog/images/2024-02-05/bodyimg6.webp b/docs/blog/images/2024-02-05/bodyimg6.webp
new file mode 100644
index 0000000000..eb69a68c8b
Binary files /dev/null and b/docs/blog/images/2024-02-05/bodyimg6.webp differ
diff --git a/docs/blog/images/2024-02-05/featured_img.png b/docs/blog/images/2024-02-05/featured_img.png
new file mode 100644
index 0000000000..586caeb967
Binary files /dev/null and b/docs/blog/images/2024-02-05/featured_img.png differ
diff --git a/docs/blog/images/2024-02-06/bodyimg1.png b/docs/blog/images/2024-02-06/bodyimg1.png
new file mode 100644
index 0000000000..1b98a7995c
Binary files /dev/null and b/docs/blog/images/2024-02-06/bodyimg1.png differ
diff --git a/docs/blog/images/2024-02-06/bodyimg2.png b/docs/blog/images/2024-02-06/bodyimg2.png
new file mode 100644
index 0000000000..3ce4570aaf
Binary files /dev/null and b/docs/blog/images/2024-02-06/bodyimg2.png differ
diff --git a/docs/blog/images/2024-02-06/bodyimg3.png b/docs/blog/images/2024-02-06/bodyimg3.png
new file mode 100644
index 0000000000..880fc9347b
Binary files /dev/null and b/docs/blog/images/2024-02-06/bodyimg3.png differ
diff --git a/docs/blog/images/2024-02-06/bodyimg4.png b/docs/blog/images/2024-02-06/bodyimg4.png
new file mode 100644
index 0000000000..aae89fc26c
Binary files /dev/null and b/docs/blog/images/2024-02-06/bodyimg4.png differ
diff --git a/docs/blog/images/2024-02-06/featured_img.png b/docs/blog/images/2024-02-06/featured_img.png
new file mode 100644
index 0000000000..17d1308903
Binary files /dev/null and b/docs/blog/images/2024-02-06/featured_img.png differ
diff --git a/docs/blog/images/2024-02-07/bodyimg1.webp b/docs/blog/images/2024-02-07/bodyimg1.webp
new file mode 100644
index 0000000000..cd42fddead
Binary files /dev/null and b/docs/blog/images/2024-02-07/bodyimg1.webp differ
diff --git a/docs/blog/images/2024-02-07/bodyimg2.webp b/docs/blog/images/2024-02-07/bodyimg2.webp
new file mode 100644
index 0000000000..95a3d9c23f
Binary files /dev/null and b/docs/blog/images/2024-02-07/bodyimg2.webp differ
diff --git a/docs/blog/images/2024-02-07/bodyimg3.webp b/docs/blog/images/2024-02-07/bodyimg3.webp
new file mode 100644
index 0000000000..d193a1618c
Binary files /dev/null and b/docs/blog/images/2024-02-07/bodyimg3.webp differ
diff --git a/docs/blog/images/2024-02-07/bodyimg4.webp b/docs/blog/images/2024-02-07/bodyimg4.webp
new file mode 100644
index 0000000000..8dc1c26c88
Binary files /dev/null and b/docs/blog/images/2024-02-07/bodyimg4.webp differ
diff --git a/docs/blog/images/2024-02-07/featured_img.png b/docs/blog/images/2024-02-07/featured_img.png
new file mode 100644
index 0000000000..bd7b63bf1c
Binary files /dev/null and b/docs/blog/images/2024-02-07/featured_img.png differ
diff --git a/docs/blog/images/2024-02-09/bodyimg1.webp b/docs/blog/images/2024-02-09/bodyimg1.webp
new file mode 100644
index 0000000000..59e086e944
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg1.webp differ
diff --git a/docs/blog/images/2024-02-09/bodyimg2.webp b/docs/blog/images/2024-02-09/bodyimg2.webp
new file mode 100644
index 0000000000..55b4dc9034
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg2.webp differ
diff --git a/docs/blog/images/2024-02-09/bodyimg3.webp b/docs/blog/images/2024-02-09/bodyimg3.webp
new file mode 100644
index 0000000000..ef195c0dde
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg3.webp differ
diff --git a/docs/blog/images/2024-02-09/bodyimg4.webp b/docs/blog/images/2024-02-09/bodyimg4.webp
new file mode 100644
index 0000000000..8f835c5609
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg4.webp differ
diff --git a/docs/blog/images/2024-02-09/bodyimg5.png b/docs/blog/images/2024-02-09/bodyimg5.png
new file mode 100644
index 0000000000..25cd791d61
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg5.png differ
diff --git a/docs/blog/images/2024-02-09/bodyimg6.png b/docs/blog/images/2024-02-09/bodyimg6.png
new file mode 100644
index 0000000000..dc9b2d6b7b
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg6.png differ
diff --git a/docs/blog/images/2024-02-09/bodyimg7.webp b/docs/blog/images/2024-02-09/bodyimg7.webp
new file mode 100644
index 0000000000..f6e5caf9a8
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg7.webp differ
diff --git a/docs/blog/images/2024-02-09/bodyimg8.webp b/docs/blog/images/2024-02-09/bodyimg8.webp
new file mode 100644
index 0000000000..c28bdf1d28
Binary files /dev/null and b/docs/blog/images/2024-02-09/bodyimg8.webp differ
diff --git a/docs/blog/images/2024-02-09/featured_img.png b/docs/blog/images/2024-02-09/featured_img.png
new file mode 100644
index 0000000000..01916254b2
Binary files /dev/null and b/docs/blog/images/2024-02-09/featured_img.png differ
diff --git a/docs/blog/images/2024-02-15/featured_img.png b/docs/blog/images/2024-02-15/featured_img.png
new file mode 100644
index 0000000000..0279ba02ef
Binary files /dev/null and b/docs/blog/images/2024-02-15/featured_img.png differ
diff --git a/docs/blog/images/2024-03-20/bodyimg1.webp b/docs/blog/images/2024-03-20/bodyimg1.webp
new file mode 100644
index 0000000000..8b3960f106
Binary files /dev/null and b/docs/blog/images/2024-03-20/bodyimg1.webp differ
diff --git a/docs/blog/images/2024-03-20/bodyimg2.avif b/docs/blog/images/2024-03-20/bodyimg2.avif
new file mode 100644
index 0000000000..0e03806189
Binary files /dev/null and b/docs/blog/images/2024-03-20/bodyimg2.avif differ
diff --git a/docs/blog/images/2024-03-20/bodyimg3.avif b/docs/blog/images/2024-03-20/bodyimg3.avif
new file mode 100644
index 0000000000..74d6865dde
Binary files /dev/null and b/docs/blog/images/2024-03-20/bodyimg3.avif differ
diff --git a/docs/blog/images/2024-03-20/featured_img.png b/docs/blog/images/2024-03-20/featured_img.png
new file mode 100644
index 0000000000..bec6fe0125
Binary files /dev/null and b/docs/blog/images/2024-03-20/featured_img.png differ
diff --git a/docs/blog/images/2024-03-21/bodyimg1.webp b/docs/blog/images/2024-03-21/bodyimg1.webp
new file mode 100644
index 0000000000..0fab6e2898
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg1.webp differ
diff --git a/docs/blog/images/2024-03-21/bodyimg2.webp b/docs/blog/images/2024-03-21/bodyimg2.webp
new file mode 100644
index 0000000000..e6878a8e07
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg2.webp differ
diff --git a/docs/blog/images/2024-03-21/bodyimg3.webp b/docs/blog/images/2024-03-21/bodyimg3.webp
new file mode 100644
index 0000000000..9a3fc263d8
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg3.webp differ
diff --git a/docs/blog/images/2024-03-21/bodyimg4.webp b/docs/blog/images/2024-03-21/bodyimg4.webp
new file mode 100644
index 0000000000..adbd03a3e8
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg4.webp differ
diff --git a/docs/blog/images/2024-03-21/bodyimg5.webp b/docs/blog/images/2024-03-21/bodyimg5.webp
new file mode 100644
index 0000000000..0be6180ed7
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg5.webp differ
diff --git a/docs/blog/images/2024-03-21/bodyimg6.webp b/docs/blog/images/2024-03-21/bodyimg6.webp
new file mode 100644
index 0000000000..e07020395a
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg6.webp differ
diff --git a/docs/blog/images/2024-03-21/bodyimg7.webp b/docs/blog/images/2024-03-21/bodyimg7.webp
new file mode 100644
index 0000000000..665eda1408
Binary files /dev/null and b/docs/blog/images/2024-03-21/bodyimg7.webp differ
diff --git a/docs/blog/images/2024-03-21/featured_img.png b/docs/blog/images/2024-03-21/featured_img.png
new file mode 100644
index 0000000000..809d4bfc73
Binary files /dev/null and b/docs/blog/images/2024-03-21/featured_img.png differ
diff --git a/docs/blog/images/2024-03-21/featured_img.webp b/docs/blog/images/2024-03-21/featured_img.webp
new file mode 100644
index 0000000000..805383519a
Binary files /dev/null and b/docs/blog/images/2024-03-21/featured_img.webp differ
diff --git a/docs/blog/images/2024-04-19/bodyimg1.webp b/docs/blog/images/2024-04-19/bodyimg1.webp
new file mode 100644
index 0000000000..65500cf317
Binary files /dev/null and b/docs/blog/images/2024-04-19/bodyimg1.webp differ
diff --git a/docs/blog/images/2024-04-19/bodyimg2.webp b/docs/blog/images/2024-04-19/bodyimg2.webp
new file mode 100644
index 0000000000..c804a5a905
Binary files /dev/null and b/docs/blog/images/2024-04-19/bodyimg2.webp differ
diff --git a/docs/blog/images/2024-04-19/bodyimg3.webp b/docs/blog/images/2024-04-19/bodyimg3.webp
new file mode 100644
index 0000000000..50faf9a8ed
Binary files /dev/null and b/docs/blog/images/2024-04-19/bodyimg3.webp differ
diff --git a/docs/blog/images/2024-04-19/bodyimg4.webp b/docs/blog/images/2024-04-19/bodyimg4.webp
new file mode 100644
index 0000000000..cdbb196f4f
Binary files /dev/null and b/docs/blog/images/2024-04-19/bodyimg4.webp differ
diff --git a/docs/blog/images/2024-04-19/featured_img.png b/docs/blog/images/2024-04-19/featured_img.png
new file mode 100644
index 0000000000..21fcaa64d6
Binary files /dev/null and b/docs/blog/images/2024-04-19/featured_img.png differ
diff --git a/docs/blog/images/authors/Colum Ferry.jpeg b/docs/blog/images/authors/Colum Ferry.jpeg
new file mode 100644
index 0000000000..22a23d4c17
Binary files /dev/null and b/docs/blog/images/authors/Colum Ferry.jpeg differ
diff --git a/docs/blog/images/authors/Emily Xiong.jpeg b/docs/blog/images/authors/Emily Xiong.jpeg
new file mode 100644
index 0000000000..b366308f5f
Binary files /dev/null and b/docs/blog/images/authors/Emily Xiong.jpeg differ
diff --git a/docs/blog/images/authors/Isaac Mann.jpeg b/docs/blog/images/authors/Isaac Mann.jpeg
new file mode 100644
index 0000000000..bb70c83012
Binary files /dev/null and b/docs/blog/images/authors/Isaac Mann.jpeg differ
diff --git a/docs/blog/images/authors/Juri Strumpflohner.jpeg b/docs/blog/images/authors/Juri Strumpflohner.jpeg
new file mode 100644
index 0000000000..3697052208
Binary files /dev/null and b/docs/blog/images/authors/Juri Strumpflohner.jpeg differ
diff --git a/docs/blog/images/authors/Katerina Skroumpelou.jpeg b/docs/blog/images/authors/Katerina Skroumpelou.jpeg
new file mode 100644
index 0000000000..4e7c485656
Binary files /dev/null and b/docs/blog/images/authors/Katerina Skroumpelou.jpeg differ
diff --git a/docs/blog/images/authors/Victor Savkin.jpeg b/docs/blog/images/authors/Victor Savkin.jpeg
new file mode 100644
index 0000000000..81c304f94c
Binary files /dev/null and b/docs/blog/images/authors/Victor Savkin.jpeg differ
diff --git a/docs/blog/images/authors/Zack DeRose.jpeg b/docs/blog/images/authors/Zack DeRose.jpeg
new file mode 100644
index 0000000000..c535a1761a
Binary files /dev/null and b/docs/blog/images/authors/Zack DeRose.jpeg differ
diff --git a/nx-dev/data-access-documents/src/lib/blog.api.ts b/nx-dev/data-access-documents/src/lib/blog.api.ts
new file mode 100644
index 0000000000..bf05ac3183
--- /dev/null
+++ b/nx-dev/data-access-documents/src/lib/blog.api.ts
@@ -0,0 +1,78 @@
+import { readFileSync, readdirSync } from 'fs';
+import { join, basename } from 'path';
+import { extractFrontmatter } from '@nx/nx-dev/ui-markdoc';
+import { sortPosts } from './blog.util';
+import { BlogPostDataEntry } from './blog.model';
+
+export class BlogApi {
+  constructor(
+    private readonly options: {
+      id: string;
+      blogRoot: string;
+    }
+  ) {
+    if (!options.id) {
+      throw new Error('id cannot be undefined');
+    }
+    if (!options.blogRoot) {
+      throw new Error('public blog root cannot be undefined');
+    }
+  }
+
+  getBlogPosts(): BlogPostDataEntry[] {
+    const files: string[] = readdirSync(this.options.blogRoot);
+    const allPosts: BlogPostDataEntry[] = [];
+
+    for (const file of files) {
+      const filePath = join(this.options.blogRoot, file);
+      // filter out directories (e.g. images)
+      if (!filePath.endsWith('.md')) continue;
+
+      const content = readFileSync(filePath, 'utf8');
+      const frontmatter = extractFrontmatter(content);
+      const slug = this.calculateSlug(filePath, frontmatter);
+      const post = {
+        content,
+        title: frontmatter.title ?? null,
+        description: frontmatter.description ?? null,
+        authors: frontmatter.authors ?? [],
+        date: this.calculateDate(file, frontmatter),
+        cover_image: frontmatter.cover_image
+          ? `/documentation${frontmatter.cover_image}` // Match the prefix used by markdown parser
+          : null,
+        tags: frontmatter.tags ?? [],
+        reposts: frontmatter.reposts ?? [],
+        pinned: frontmatter.pinned ?? false,
+        filePath,
+        slug,
+      };
+
+      if (!frontmatter.draft || process.env.NODE_ENV === 'development') {
+        allPosts.push(post);
+      }
+    }
+
+    return sortPosts(allPosts);
+  }
+
+  private calculateSlug(filePath: string, frontmatter: any): string {
+    const baseName = basename(filePath, '.md');
+    return frontmatter.slug || baseName;
+  }
+
+  private calculateDate(filename: string, frontmatter: any): string {
+    const date: Date = new Date();
+    const timeString = date.toTimeString();
+    if (frontmatter.date) {
+      return new Date(frontmatter.date + ' ' + timeString).toISOString();
+    } else {
+      const regexp = /^(\d\d\d\d-\d\d-\d\d).+$/;
+      const match = filename.match(regexp);
+      if (match) {
+        return new Date(match[1] + ' ' + timeString).toISOString();
+      } else {
+        throw new Error(`Could not parse date from filename: ${filename}`);
+      }
+    }
+  }
+}
diff --git a/nx-dev/data-access-documents/src/lib/blog.model.ts b/nx-dev/data-access-documents/src/lib/blog.model.ts
new file mode 100644
index 0000000000..d30616818b
--- /dev/null
+++ b/nx-dev/data-access-documents/src/lib/blog.model.ts
@@ -0,0 +1,14 @@
+export type BlogPostDataEntry = {
+  title: string;
+  content: string;
+  description: string;
+  authors: string[];
+  date: string;
+  cover_image: string | null;
+  tags: string[];
+  reposts: string[];
+  updated?: string;
+  pinned?: boolean;
+  filePath: string;
+  slug: string;
+};
diff --git a/nx-dev/data-access-documents/src/lib/blog.util.spec.ts b/nx-dev/data-access-documents/src/lib/blog.util.spec.ts
new file mode 100644
index 0000000000..5048e977e5
--- /dev/null
+++ b/nx-dev/data-access-documents/src/lib/blog.util.spec.ts
@@ -0,0 +1,70 @@
+import { sortPosts } from './blog.util';
+
+describe('sortPosts', () => {
+  test('sort from latest to earliest', () => {
+    const posts = [
+      createPost({ date: '2022-01-01', title: 'Post 1', slug: 'post-1' }),
+      createPost({ date: '2023-01-01', title: 'Post 2', slug: 'post-2' }),
+    ];
+
+    const results = sortPosts(posts);
+
+    expect(results.map((p) => p.slug)).toEqual(['post-2', 'post-1']);
+  });
+
+  test('latest pinned posts are presented first', () => {
+    const posts = [
+      createPost({
+        date: '2023-01-01',
+        title: 'Post 1',
+        slug: 'post-1',
+        pinned: true,
+      }),
+      createPost({ date: '2023-02-01', title: 'Post 2', slug: 'post-2' }),
+      createPost({
+        date: '2023-03-01',
+        title: 'Post 3',
+        slug: 'post-3',
+        pinned: true,
+      }),
+      createPost({
+        date: '2023-04-01',
+        title: 'Post 4',
+        slug: 'post-4',
+        pinned: true,
+      }),
+      createPost({ date: '2023-05-01', title: 'Post 5', slug: 'post-5' }),
+    ];
+
+    const results = sortPosts(posts);
+
+    expect(results.map((p) => p.slug)).toEqual([
+      'post-4',
+      'post-3',
+      'post-1',
+      'post-5',
+      'post-2',
+    ]);
+  });
+});
+
+function createPost(data: {
+  date: string;
+  title: string;
+  slug: string;
+  pinned?: boolean;
+}) {
+  return {
+    content: '',
+    filePath: `${data.slug}.md`,
+    slug: data.slug,
+    date: data.date,
+    title: data.title,
+    description: '',
+    authors: [],
+    cover_image: '',
+    tags: [],
+    reposts: [],
+    pinned: data.pinned ?? undefined,
+  };
+}
diff --git a/nx-dev/data-access-documents/src/lib/blog.util.ts b/nx-dev/data-access-documents/src/lib/blog.util.ts
new file mode 100644
index 0000000000..5b30e9efcf
--- /dev/null
+++ b/nx-dev/data-access-documents/src/lib/blog.util.ts
@@ -0,0 +1,9 @@
+import { BlogPostDataEntry } from './blog.model';
+
+export function sortPosts(posts: BlogPostDataEntry[]): BlogPostDataEntry[] {
+  return posts.sort((a, b) => {
+    if (a.pinned && !b.pinned) return -1;
+    if (b.pinned && !a.pinned) return 1;
+    return new Date(b.date).getTime() - new Date(a.date).getTime();
+  });
+}
diff --git a/nx-dev/data-access-documents/src/node.index.ts b/nx-dev/data-access-documents/src/node.index.ts
index b287841139..c829d2e6a5 100644
--- a/nx-dev/data-access-documents/src/node.index.ts
+++ b/nx-dev/data-access-documents/src/node.index.ts
@@ -1,3 +1,6 @@
 export * from './lib/documents.api';
 export * from './lib/changelog.api';
+export * from './lib/blog.util';
+export * from './lib/blog.api';
+export * from './lib/blog.model';
 export * from './lib/tags.api';
diff --git a/nx-dev/nx-dev/copy-docs.js b/nx-dev/nx-dev/copy-docs.js
index 04940d8000..08eb85a8ba 100644
--- a/nx-dev/nx-dev/copy-docs.js
+++ b/nx-dev/nx-dev/copy-docs.js
@@ -1,9 +1,13 @@
-const { copySync } = require('fs-extra');
+const { copySync, rmSync } = require('fs-extra');
 const path = require('path');
 
 /**
  * Copies the documentation into the proper Next.js public folder
  */
+rmSync(path.resolve(path.join(__dirname, 'public/documentation')), {
+  recursive: true,
+  force: true,
+});
 copySync(
   path.resolve(path.join(__dirname, '../../docs')),
   path.resolve(path.join(__dirname, 'public/documentation')),
diff --git a/nx-dev/nx-dev/lib/blog.api.ts b/nx-dev/nx-dev/lib/blog.api.ts
new file mode 100644
index 0000000000..d59c7f0539
--- /dev/null
+++ b/nx-dev/nx-dev/lib/blog.api.ts
@@ -0,0 +1,6 @@
+import { BlogApi } from '@nx/nx-dev/data-access-documents/node-only';
+
+export const blogApi = new BlogApi({
+  id: 'blog',
+  blogRoot: 'public/documentation/blog',
+});
diff --git a/nx-dev/nx-dev/pages/blog/[slug].tsx b/nx-dev/nx-dev/pages/blog/[slug].tsx
new file mode 100644
index 0000000000..4063f5a792
--- /dev/null
+++ b/nx-dev/nx-dev/pages/blog/[slug].tsx
@@ -0,0 +1,64 @@
+import { GetStaticProps, GetStaticPaths } from 'next';
+import { blogApi } from '../../lib/blog.api';
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
+import { NextSeo } from 'next-seo';
+import { Footer, Header } from '@nx/nx-dev/ui-common';
+import { BlogDetails } from '@nx/nx-dev/ui-blog';
+
+interface BlogPostDetailProps {
+  post: BlogPostDataEntry;
+}
+
+export default function BlogPostDetail({ post }: BlogPostDetailProps) {
+  return (
+    <>
+      <NextSeo
+        title={`${post.title} | Nx Blog`}
+        description="Latest news from the Nx & Nx Cloud core team"
+        openGraph={{
+          url: 'https://nx.dev', // + router.asPath,
+          title: post.title,
+          description: post.description,
+          images: [
+            {
+              url: post.cover_image
+                ? `https://nx.dev${post.cover_image}`
+                : 'https://nx.dev/socials/nx-media.png',
+              width: 800,
+              height: 421,
+              alt: 'Nx: Smart, Fast and Extensible Build System',
+              type: 'image/jpeg',
+            },
+          ],
+          siteName: 'NxDev',
+          type: 'website',
+        }}
+      />
+      <Header />
+      <BlogDetails post={post} />
+      <Footer />
+    </>
+  );
+}
+
+export const getStaticProps: GetStaticProps = async (context) => {
+  // optimize s.t. we don't read the FS multiple times; for now it's ok
+  const posts = await blogApi.getBlogPosts();
+  const post = posts.find((p) => p.slug === context.params?.slug);
+
+  return {
+    props: {
+      post,
+    },
+  };
+};
+
+export const getStaticPaths: GetStaticPaths = async () => {
+  const posts = await blogApi.getBlogPosts();
+
+  const paths = posts.map((post) => ({
+    params: { slug: post.slug },
+  }));
+
+  return { paths, fallback: false };
+};
diff --git a/nx-dev/nx-dev/pages/blog/index.tsx b/nx-dev/nx-dev/pages/blog/index.tsx
index 24734f7d0a..e534928a13 100644
--- a/nx-dev/nx-dev/pages/blog/index.tsx
+++ b/nx-dev/nx-dev/pages/blog/index.tsx
@@ -1,18 +1,35 @@
-import { Footer, Header, SectionHeading } from '@nx/nx-dev/ui-common';
+import { Footer, Header } from '@nx/nx-dev/ui-common';
 import { NextSeo } from 'next-seo';
 import { useRouter } from 'next/router';
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
 
-export default function Blog(): JSX.Element {
+import { blogApi } from '../../lib/blog.api';
+import { BlogContainer } from '@nx/nx-dev/ui-blog';
+
+interface BlogListProps {
+  blogposts: BlogPostDataEntry[];
+}
+
+export function getStaticProps(): { props: BlogListProps } {
+  const blogposts = blogApi.getBlogPosts();
+  return {
+    props: {
+      blogposts,
+    },
+  };
+}
+
+export default function Blog({ blogposts }: BlogListProps): JSX.Element {
   const router = useRouter();
 
   return (
     <>
       <NextSeo
-        title="Nx Blog"
+        title="Nx Blog - Updates from the Nx & Nx Cloud team"
         description="Latest news from the Nx & Nx Cloud core team"
         openGraph={{
           url: 'https://nx.dev' + router.asPath,
-          title: 'Nx Blog',
+          title: 'Nx Blog - Updates from the Nx & Nx Cloud team',
           description:
             'Stay updated with the latest news, articles, and updates from the Nx & Nx Cloud team.',
           images: [
@@ -29,129 +46,7 @@ export default function Blog(): JSX.Element {
         }}
       />
       <Header />
-      <main id="main" role="main">
-        <div className="w-full">
-          <div className="py-8 bg-slate-50 dark:bg-slate-800/40">
-            <article className="mx-auto max-w-7xl px-4 pt-12 sm:px-6 lg:items-center lg:py-4 lg:px-8">
-              <header className="md:py-8">
-                <div>
-                  <SectionHeading as="h1" variant="display" id="blog-title">
-                    The Nx Blog
-                  </SectionHeading>
-                  <p className="pt-5 text-lg text-slate-700 dark:text-slate-400">
-                    Coming soon...
-                  </p>
-                </div>
-              </header>
-              <p className="pt-5  text-lg text-slate-700 dark:text-slate-400">
-                And while we're working on getting our new shiny blog up and
-                running, check out our current blog posts on Medium and Dev.to.
-                Or sit back, relax and watch some of our video content on
-                Youtube.
-              </p>
-            </article>
-            <section className="mx-auto max-w-7xl px-4 pt-12 grid grid-cols-1 gap-5 md:grid-cols-3 pb-24">
-              <div className="group relative rounded-lg border border-slate-200 bg-white/60 p-5 transition duration-200 ease-out hover:border-slate-300 dark:border-slate-800/40 dark:bg-slate-800/60 dark:hover:border-slate-900 dark:hover:bg-slate-800">
-                <div className="relative m-2 mb-6 inline-flex h-10 w-10 items-center justify-center">
-                  <div className="absolute inset-0 -m-2 rotate-6 transform rounded-3xl bg-slate-300 transition duration-200 ease-out group-hover:-rotate-3 group-hover:scale-105 dark:bg-slate-800" />
-                  <div className="absolute inset-0 -rotate-6 transform rounded-2xl bg-[#000000] bg-opacity-75 shadow-inner transition duration-200 ease-out group-hover:rotate-2 group-hover:scale-105" />
-                  <svg
-                    fill="currentColor"
-                    className="relative inline-block h-5 w-5 transform text-white transition duration-200 ease-out group-hover:scale-110"
-                    role="img"
-                    viewBox="0 0 24 24"
-                    xmlns="http://www.w3.org/2000/svg"
-                  >
-                    <title>Medium</title>
-                    <path d="M13.54 12a6.8 6.8 0 01-6.77 6.82A6.8 6.8 0 010 12a6.8 6.8 0 016.77-6.82A6.8 6.8 0 0113.54 12zM20.96 12c0 3.54-1.51 6.42-3.38 6.42-1.87 0-3.39-2.88-3.39-6.42s1.52-6.42 3.39-6.42 3.38 2.88 3.38 6.42M24 12c0 3.17-.53 5.75-1.19 5.75-.66 0-1.19-2.58-1.19-5.75s.53-5.75 1.19-5.75C23.47 6.25 24 8.83 24 12z" />
-                  </svg>
-                </div>
-                <h4 className="mb-2 text-lg font-bold">
-                  Current, official "Nrwl" blog
-                </h4>
-                <a
-                  href="https://blog.nrwl.io"
-                  rel="noreferrer"
-                  target="_blank"
-                  title="Nx Blog"
-                  className="focus:outline-none"
-                >
-                  <span className="absolute inset-0" aria-hidden="true"></span>
-                  <p className="leading-relaxed">
-                    Read all of the latest news on our current - soon to be
-                    sunset - official Nx aka Nrwl Blog.
-                  </p>
-                </a>
-              </div>
-              <div className="group relative rounded-lg border border-slate-200 bg-white/60 p-5 transition duration-200 ease-out hover:border-indigo-300 dark:border-slate-800/40 dark:bg-slate-800/60 dark:hover:border-indigo-900 dark:hover:bg-slate-800">
-                <div className="relative m-2 mb-6 inline-flex h-10 w-10 items-center justify-center">
-                  <div className="absolute inset-0 -m-2 rotate-6 transform rounded-3xl bg-indigo-300 transition duration-200 ease-out group-hover:-rotate-3 group-hover:scale-105 dark:bg-indigo-900" />
-                  <div className="absolute inset-0 -rotate-6 transform rounded-2xl bg-[#5865F2] bg-opacity-75 shadow-inner transition duration-200 ease-out group-hover:rotate-2 group-hover:scale-105" />
-                  <svg
-                    role="img"
-                    fill="currentColor"
-                    className="relative inline-block h-5 w-5 transform text-white transition duration-200 ease-out group-hover:scale-110"
-                    viewBox="0 0 24 24"
-                    xmlns="http://www.w3.org/2000/svg"
-                  >
-                    <title>dev.to</title>
-                    <path d="M7.42 10.05c-.18-.16-.46-.23-.84-.23H6l.02 2.44.04 2.45.56-.02c.41 0 .63-.07.83-.26.24-.24.26-.36.26-2.2 0-1.91-.02-1.96-.29-2.18zM0 4.94v14.12h24V4.94H0zM8.56 15.3c-.44.58-1.06.77-2.53.77H4.71V8.53h1.4c1.67 0 2.16.18 2.6.9.27.43.29.6.32 2.57.05 2.23-.02 2.73-.47 3.3zm5.09-5.47h-2.47v1.77h1.52v1.28l-.72.04-.75.03v1.77l1.22.03 1.2.04v1.28h-1.6c-1.53 0-1.6-.01-1.87-.3l-.3-.28v-3.16c0-3.02.01-3.18.25-3.48.23-.31.25-.31 1.88-.31h1.64v1.3zm4.68 5.45c-.17.43-.64.79-1 .79-.18 0-.45-.15-.67-.39-.32-.32-.45-.63-.82-2.08l-.9-3.39-.45-1.67h.76c.4 0 .75.02.75.05 0 .06 1.16 4.54 1.26 4.83.04.15.32-.7.73-2.3l.66-2.52.74-.04c.4-.02.73 0 .73.04 0 .14-1.67 6.38-1.8 6.68z" />
-                  </svg>
-                </div>
-                <h4 className="mb-2 text-lg font-bold">
-                  We're on Dev.to, too!
-                </h4>
-                <a
-                  href="https://dev.to/nx"
-                  rel="noreferrer"
-                  target="_blank"
-                  title="Nx Blog"
-                  className="focus:outline-none"
-                >
-                  <span className="absolute inset-0" aria-hidden="true"></span>
-                  <p className="leading-relaxed">
-                    You're not really into Medium? Prefer dev.to? Good news, we
-                    cross-post most of our articles to a Dev.to collection.
-                  </p>
-                </a>
-              </div>
-              <div className="group relative rounded-lg border border-slate-200 bg-white/60 p-5 transition duration-200 ease-out hover:border-red-300 dark:border-slate-800/40 dark:bg-slate-800/60 dark:hover:border-red-900 dark:hover:bg-slate-800">
-                <div className="relative m-2 mb-6 inline-flex h-10 w-10 items-center justify-center">
-                  <div className="absolute inset-0 -m-2 rotate-6 transform rounded-3xl bg-red-300 transition duration-200 ease-out group-hover:-rotate-3 group-hover:scale-105 dark:bg-red-900" />
-                  <div className="absolute inset-0 -rotate-6 transform rounded-2xl bg-[#FF0000] bg-opacity-75 shadow-inner transition duration-200 ease-out group-hover:rotate-2 group-hover:scale-105" />
-                  <svg
-                    fill="currentColor"
-                    className="hi-solid hi-chart-pie relative inline-block h-5 w-5 transform text-white transition duration-200 ease-out group-hover:scale-110"
-                    role="img"
-                    viewBox="0 0 24 24"
-                    xmlns="http://www.w3.org/2000/svg"
-                  >
-                    <title>YouTube</title>
-                    <path d="M23.498 6.186a3.016 3.016 0 0 0-2.122-2.136C19.505 3.545 12 3.545 12 3.545s-7.505 0-9.377.505A3.017 3.017 0 0 0 .502 6.186C0 8.07 0 12 0 12s0 3.93.502 5.814a3.016 3.016 0 0 0 2.122 2.136c1.871.505 9.376.505 9.376.505s7.505 0 9.377-.505a3.015 3.015 0 0 0 2.122-2.136C24 15.93 24 12 24 12s0-3.93-.502-5.814zM9.545 15.568V8.432L15.818 12l-6.273 3.568z" />
-                  </svg>
-                </div>
-                <h4 className="mb-2 text-lg font-bold">
-                  Prefer Video Content?
-                </h4>
-                <a
-                  href="https://www.youtube.com/@NxDevtools/videos?utm_source=nx.dev"
-                  rel="noreferrer"
-                  target="_blank"
-                  title="Nx Youtube channel"
-                  className="focus:outline-none"
-                >
-                  <span className="absolute inset-0" aria-hidden="true"></span>
-                  <p className="leading-relaxed">
-                    Not into reading right now? Then go to our YT channel to
-                    enjoy some short informative clips, release videos or live
-                    Q&A sessions. Don't forget to subscribe while you're there!
-                  </p>
-                </a>
-              </div>
-            </section>
-          </div>
-        </div>
-      </main>
+      <BlogContainer blogPosts={blogposts} />
       <Footer />
     </>
   );
diff --git a/nx-dev/nx-dev/styles/main.css b/nx-dev/nx-dev/styles/main.css
index b74f26ab05..c4cd55f14c 100644
--- a/nx-dev/nx-dev/styles/main.css
+++ b/nx-dev/nx-dev/styles/main.css
@@ -82,6 +82,10 @@ iframe[src*='youtube'] {
   font-weight: 600;
 }
 
+.prose .twitter-tweet {
+  margin: 0 auto;
+}
+
 /**
  * Tooltips
  */
diff --git a/nx-dev/ui-blog/.eslintrc.json b/nx-dev/ui-blog/.eslintrc.json
new file mode 100644
index 0000000000..8d4e2111db
--- /dev/null
+++ b/nx-dev/ui-blog/.eslintrc.json
@@ -0,0 +1,18 @@
+{
+  "extends": ["../../.eslintrc.base.json"],
+  "ignorePatterns": ["!**/*"],
+  "overrides": [
+    {
+      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
+      "rules": {}
+    },
+    {
+      "files": ["*.ts", "*.tsx"],
+      "rules": {}
+    },
+    {
+      "files": ["*.js", "*.jsx"],
+      "rules": {}
+    }
+  ]
+}
diff --git a/nx-dev/ui-blog/README.md b/nx-dev/ui-blog/README.md
new file mode 100644
index 0000000000..edb0c73bbf
--- /dev/null
+++ b/nx-dev/ui-blog/README.md
@@ -0,0 +1,3 @@
+# ui-blog
+
+This library was generated with [Nx](https://nx.dev).
diff --git a/nx-dev/ui-blog/project.json b/nx-dev/ui-blog/project.json
new file mode 100644
index 0000000000..971e9d1589
--- /dev/null
+++ b/nx-dev/ui-blog/project.json
@@ -0,0 +1,9 @@
+{
+  "name": "ui-blog",
+  "$schema": "../../node_modules/nx/schemas/project-schema.json",
+  "sourceRoot": "nx-dev/ui-blog/src",
+  "projectType": "library",
+  "tags": [],
+  "// targets": "to see all targets run: nx show project ui-blog --web",
+  "targets": {}
+}
diff --git a/nx-dev/ui-blog/src/index.ts b/nx-dev/ui-blog/src/index.ts
new file mode 100644
index 0000000000..58c41ad0f3
--- /dev/null
+++ b/nx-dev/ui-blog/src/index.ts
@@ -0,0 +1,6 @@
+export { BlogAuthors } from './lib/authors';
+export { BlogEntry, BlogEntryProps } from './lib/blog-entry';
+export { MoreBlogs, MoreBlogsProps } from './lib/more-blogs';
+export { BlogDetails, BlogDetailsProps } from './lib/blog-details';
+export { BlogContainer } from './lib/blog-container';
+export { FeaturedBlogs } from './lib/featured-blogs';
diff --git a/nx-dev/ui-blog/src/lib/authors.tsx b/nx-dev/ui-blog/src/lib/authors.tsx
new file mode 100644
index 0000000000..37311d395a
--- /dev/null
+++ b/nx-dev/ui-blog/src/lib/authors.tsx
@@ -0,0 +1,21 @@
+import Image from 'next/image';
+
+export function BlogAuthors({ authors }: { authors: string[] }): JSX.Element {
+  return (
+    <div className="isolate flex items-center -space-x-2 overflow-hidden">
+      {authors.map((author, index) => (
+        <Image
+          key={index}
+          alt={author}
+          title={author}
+          loading="lazy"
+          width="48"
+          height="48"
+          decoding="async"
+          src={`/documentation/blog/images/authors/${author}.jpeg`}
+          className="relative inline-block h-6 w-6 rounded-full ring-1 ring-white grayscale dark:ring-slate-900"
+        />
+      ))}
+    </div>
+  );
+}
diff --git a/nx-dev/ui-blog/src/lib/blog-container.tsx b/nx-dev/ui-blog/src/lib/blog-container.tsx
new file mode 100644
index 0000000000..7410e45c16
--- /dev/null
+++ b/nx-dev/ui-blog/src/lib/blog-container.tsx
@@ -0,0 +1,27 @@
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
+import { MoreBlogs } from './more-blogs';
+import { FeaturedBlogs } from './featured-blogs';
+
+export interface BlogContainerProps {
+  blogPosts: BlogPostDataEntry[];
+}
+
+export function BlogContainer({ blogPosts }: BlogContainerProps) {
+  const [blog1, blog2, blog3, blog4, blog5, ...restOfPosts] = blogPosts;
+  return (
+    <main id="main" role="main" className="w-full py-8">
+      <div className="mx-auto mb-8 w-full max-w-[1088px] px-8">
+        <header className="mx-auto mb-16">
+          <h1
+            id="blog-title"
+            className="text-xl font-semibold tracking-tight text-slate-900 md:text-2xl dark:text-slate-100"
+          >
+            Blog
+          </h1>
+        </header>
+        <FeaturedBlogs blogs={[blog1, blog2, blog3, blog4, blog5]} />
+        {restOfPosts.length > 0 ? <MoreBlogs blogs={restOfPosts} /> : null}
+      </div>
+    </main>
+  );
+}
diff --git a/nx-dev/ui-blog/src/lib/blog-details.tsx b/nx-dev/ui-blog/src/lib/blog-details.tsx
new file mode 100644
index 0000000000..dd6191e2d2
--- /dev/null
+++ b/nx-dev/ui-blog/src/lib/blog-details.tsx
@@ -0,0 +1,69 @@
+import Link from 'next/link';
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
+import Image from 'next/image';
+import { BlogAuthors } from './authors';
+import { ChevronLeftIcon } from '@heroicons/react/24/outline';
+import { renderMarkdown } from '@nx/nx-dev/ui-markdoc';
+
+export interface BlogDetailsProps {
+  post: BlogPostDataEntry;
+}
+export function BlogDetails({ post }: BlogDetailsProps) {
+  const { node } = renderMarkdown(post.content, {
+    filePath: post.filePath ?? '',
+  });
+
+  const formattedDate = new Date(post.date).toLocaleDateString('en-US', {
+    month: 'long',
+    day: 'numeric',
+    year: 'numeric',
+  });
+
+  return (
+    <main id="main" role="main" className="w-full py-8">
+      <div className="mx-auto mb-8 flex max-w-screen-xl justify-between px-4 lg:px-8">
+        <Link
+          href="/blog"
+          className="flex w-20 shrink-0 items-center gap-2 text-slate-400 hover:text-slate-800 dark:text-slate-600 dark:hover:text-slate-200"
+        >
+          <ChevronLeftIcon className="h-3 w-3" />
+          Blog
+        </Link>
+        <div className="flex max-w-sm flex-1 grow items-center justify-end gap-2">
+          <BlogAuthors authors={post.authors} />
+          <span className="text-sm text-slate-400 dark:text-slate-600">
+            {formattedDate}
+          </span>
+        </div>
+      </div>
+      <div id="content-wrapper">
+        <header className="mx-auto mb-16 mt-8 max-w-3xl px-4 lg:px-0">
+          <h1 className="text-center text-4xl font-semibold text-slate-900 dark:text-white">
+            {post.title}
+          </h1>
+        </header>
+        {post.cover_image && (
+          <div className="mx-auto mb-16 aspect-[1.9] w-full max-w-screen-md">
+            <Image
+              className="h-full w-full object-cover md:rounded-md"
+              src={post.cover_image}
+              alt={post.title}
+              width={1400}
+              height={735}
+            />
+          </div>
+        )}
+        <div className="mx-auto min-w-0 max-w-3xl flex-auto px-4 pb-24 lg:px-0 lg:pb-16">
+          <div className="relative">
+            <div
+              data-document="main"
+              className="prose prose-lg prose-slate dark:prose-invert w-full max-w-none 2xl:max-w-4xl"
+            >
+              {node}
+            </div>
+          </div>
+        </div>
+      </div>
+    </main>
+  );
+}
diff --git a/nx-dev/ui-blog/src/lib/blog-entry.tsx b/nx-dev/ui-blog/src/lib/blog-entry.tsx
new file mode 100644
index 0000000000..adecb8135c
--- /dev/null
+++ b/nx-dev/ui-blog/src/lib/blog-entry.tsx
@@ -0,0 +1,38 @@
+import Link from 'next/link';
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
+import { BlogAuthors } from './authors';
+import Image from 'next/image';
+
+export interface BlogEntryProps {
+  post: BlogPostDataEntry;
+}
+
+export function BlogEntry({ post }: BlogEntryProps) {
+  return (
+    <div className="relative flex h-full transform-gpu flex-col overflow-hidden rounded-2xl border border-slate-200 shadow transition-all duration-300 ease-in-out hover:scale-[1.02] hover:shadow-lg dark:border-slate-800">
+      {post.cover_image && (
+        <div className="aspect-[1.9] w-full">
+          <Image
+            quality={100}
+            className="h-full w-full object-cover"
+            src={post.cover_image}
+            alt={post.title}
+            width={1400}
+            height={735}
+          />
+        </div>
+      )}
+      <div className="flex flex-col gap-1 p-4">
+        <BlogAuthors authors={post.authors} />
+        <Link
+          href={`/blog/${post.slug}`}
+          title={post.title}
+          className="text-balance text-lg font-semibold text-slate-900 dark:text-white"
+        >
+          <span className="absolute inset-0" aria-hidden="true" />
+          {post.title}
+        </Link>
+      </div>
+    </div>
+  );
+}
diff --git a/nx-dev/ui-blog/src/lib/featured-blogs.tsx b/nx-dev/ui-blog/src/lib/featured-blogs.tsx
new file mode 100644
index 0000000000..6763808c52
--- /dev/null
+++ b/nx-dev/ui-blog/src/lib/featured-blogs.tsx
@@ -0,0 +1,25 @@
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
+import { BlogEntry } from './blog-entry';
+
+interface FeaturedBlogsProps {
+  blogs: BlogPostDataEntry[];
+}
+
+export function FeaturedBlogs({ blogs }: FeaturedBlogsProps) {
+  return (
+    <div className="mx-auto flex flex-col gap-4">
+      <div className="grid grid-cols-6 gap-6">
+        {blogs.map((blog, index) => (
+          <div
+            key={index}
+            className={`col-span-6 ${
+              index <= 1 ? 'md:col-span-3' : 'sm:col-span-3'
+            } ${index > 0 ? 'md:col-span-2' : ''}`}
+          >
+            <BlogEntry post={blog} />
+          </div>
+        ))}
+      </div>
+    </div>
+  );
+}
diff --git a/nx-dev/ui-blog/src/lib/more-blogs.tsx b/nx-dev/ui-blog/src/lib/more-blogs.tsx
new file mode 100644
index 0000000000..d7eb663c4f
--- /dev/null
+++ b/nx-dev/ui-blog/src/lib/more-blogs.tsx
@@ -0,0 +1,52 @@
+import Link from 'next/link';
+import { BlogPostDataEntry } from '@nx/nx-dev/data-access-documents/node-only';
+import { BlogAuthors } from './authors';
+
+export interface MoreBlogsProps {
+  blogs: BlogPostDataEntry[];
+}
+
+export function MoreBlogs({ blogs }: MoreBlogsProps) {
+  return (
+    <>
+      <div className="mx-auto mb-8 mt-20 border-b-2 border-slate-300 pb-3 text-sm dark:border-slate-700">
+        <h2 className="font-semibold">More blogs</h2>
+      </div>
+      <div className="mx-auto">
+        {blogs?.map((post) => {
+          const formattedDate = new Date(post.date).toLocaleDateString(
+            'en-US',
+            {
+              month: 'short',
+              day: '2-digit',
+              year: 'numeric',
+            }
+          );
+          const tags = post.tags.map(
+            (tag) => `${tag.substring(0, 1).toUpperCase()}${tag.substring(1)}`
+          );
+          return (
+            <Link
+              href={`/blog/${post.slug}`}
+              key={post.slug}
+              className="relative flex items-center gap-6 border-b border-slate-200 py-5 text-sm before:absolute before:inset-x-[-16px] before:inset-y-[-2px] before:z-[-1] before:rounded-xl before:bg-slate-200 before:opacity-0 last:border-0 before:hover:opacity-100 dark:border-slate-800 dark:before:bg-slate-800/50"
+            >
+              <span className="w-1/2 flex-none text-balance font-medium text-slate-500 sm:w-5/12 dark:text-white">
+                {post.title}
+              </span>
+              <span className="w-1/2 flex-none sm:w-3/12">
+                {tags.join(', ')}
+              </span>
+              <span className="hidden w-2/12 flex-none sm:inline-block">
+                {formattedDate}
+              </span>
+              <span className="hidden w-2/12 flex-none sm:inline-block">
+                <BlogAuthors authors={post.authors} />
+              </span>
+            </Link>
+          );
+        })}
+      </div>
+    </>
+  );
+}
diff --git a/nx-dev/ui-blog/tsconfig.json b/nx-dev/ui-blog/tsconfig.json
new file mode 100644
index 0000000000..6d076c06d5
--- /dev/null
+++ b/nx-dev/ui-blog/tsconfig.json
@@ -0,0 +1,20 @@
+{
+  "extends": "../../tsconfig.base.json",
+  "compilerOptions": {
+    "jsx": "react-jsx",
+    "allowJs": true,
+    "esModuleInterop": true,
+    "allowSyntheticDefaultImports": true,
+    "forceConsistentCasingInFileNames": true,
+    "strict": true,
+    "noImplicitReturns": true,
+    "noFallthroughCasesInSwitch": true
+  },
+  "files": [],
+  "include": [],
+  "references": [
+    {
+      "path": "./tsconfig.lib.json"
+    }
+  ]
+}
diff --git a/nx-dev/ui-blog/tsconfig.lib.json b/nx-dev/ui-blog/tsconfig.lib.json
new file mode 100644
index 0000000000..faa09cc186
--- /dev/null
+++ b/nx-dev/ui-blog/tsconfig.lib.json
@@ -0,0 +1,10 @@
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "outDir": "../../dist/out-tsc",
+    "declaration": true,
+    "types": ["node"]
+  },
+  "include": ["src/**/*.ts"],
+  "exclude": ["src/**/*.spec.ts", "src/**/*.test.ts"]
+}
diff --git a/nx-dev/ui-common/src/index.ts b/nx-dev/ui-common/src/index.ts
index 5511191db4..1b28c1eca7 100644
--- a/nx-dev/ui-common/src/index.ts
+++ b/nx-dev/ui-common/src/index.ts
@@ -12,14 +12,15 @@ export * from './lib/sidebar-container';
 export * from './lib/sidebar';
 export * from './lib/plugin-card';
 export * from './lib/testimonial-card';
+export * from './lib/tweet';
 export * from './lib/typography';
 export * from './lib/github-star-widget';
 export * from './lib/youtube.component';
+export * from './lib/image-theme';
 export { resourceMenuItems } from './lib/headers/menu-items';
 export { solutionsMenuItems } from './lib/headers/menu-items';
 export { eventItems } from './lib/headers/menu-items';
 export { learnItems } from './lib/headers/menu-items';
-export { useCaseItems } from './lib/headers/menu-items';
 export { plans } from './lib/headers/menu-items';
 export { featuresItems } from './lib/headers/menu-items';
 export { DefaultMenuItem } from './lib/headers/default-menu-item';
diff --git a/nx-dev/ui-common/src/lib/image-theme.tsx b/nx-dev/ui-common/src/lib/image-theme.tsx
new file mode 100644
index 0000000000..e302ab4430
--- /dev/null
+++ b/nx-dev/ui-common/src/lib/image-theme.tsx
@@ -0,0 +1,46 @@
+import Image from 'next/image';
+import { useEffect, useState } from 'react';
+
+export interface ImageThemeProps {
+  lightSrc: string;
+  darkSrc: string;
+  alt?: string;
+  [key: string]: any;
+}
+
+export function ImageTheme({
+  lightSrc,
+  darkSrc,
+  alt,
+  ...props
+}: ImageThemeProps) {
+  const [src, setSrc] = useState(lightSrc);
+
+  // Listen for theme change and update the image
+  useEffect(() => {
+    const updateImageSource = () => {
+      const isDarkMode = document.documentElement.classList.contains('dark');
+      setSrc(isDarkMode ? darkSrc : lightSrc);
+    };
+
+    updateImageSource();
+
+    // Event listener for changes in system theme
+    const themeMediaQuery = window.matchMedia('(prefers-color-scheme: dark)');
+    themeMediaQuery.addEventListener('change', updateImageSource);
+
+    const observer = new MutationObserver(updateImageSource);
+    observer.observe(document.documentElement, {
+      attributes: true,
+      attributeFilter: ['class'],
+    });
+
+    // Cleanup function to remove event listener and observer on component unmount
+    return () => {
+      themeMediaQuery.removeEventListener('change', updateImageSource);
+      observer.disconnect();
+    };
+  }, []);
+
+  return <Image src={src} alt={alt ?? ''} {...props} />;
+}
diff --git a/nx-dev/ui-common/src/lib/tweet.tsx b/nx-dev/ui-common/src/lib/tweet.tsx
new file mode 100644
index 0000000000..45e68c6e98
--- /dev/null
+++ b/nx-dev/ui-common/src/lib/tweet.tsx
@@ -0,0 +1,33 @@
+import Script from 'next/script';
+import { Schema } from '@markdoc/markdoc';
+
+export const tweet: Schema = {
+  render: 'Tweet',
+  attributes: {
+    url: {
+      type: 'String',
+      required: true,
+    },
+  },
+};
+
+export function Tweet(props: { url: string }) {
+  return (
+    <>
+      <blockquote
+        className="twitter-tweet border-0"
+        data-conversation="none"
+        data-theme="light"
+        data-lang="en"
+        data-dnt="true"
+      >
+        <a href={props.url}>Loading tweet...</a>
+      </blockquote>
+      <Script
+        async
+        src="https://platform.twitter.com/widgets.js"
+        charSet="utf-8"
+      />
+    </>
+  );
+}
diff --git a/nx-dev/ui-markdoc/src/index.ts b/nx-dev/ui-markdoc/src/index.ts
index 8bbe75fba3..24e6f72f37 100644
--- a/nx-dev/ui-markdoc/src/index.ts
+++ b/nx-dev/ui-markdoc/src/index.ts
@@ -45,6 +45,7 @@ import { SideBySide } from './lib/tags/side-by-side.component';
 import { sideBySide } from './lib/tags/side-by-side.schema';
 import { Tab, Tabs } from './lib/tags/tabs.component';
 import { tab, tabs } from './lib/tags/tabs.schema';
+import { Tweet, tweet } from '@nx/nx-dev/ui-common';
 import { YouTube, youtube } from '@nx/nx-dev/ui-common';
 import {
   TerminalVideo,
@@ -91,8 +92,9 @@ export const getMarkdocCustomConfig = (
       'side-by-side': sideBySide,
       tab,
       tabs,
-      youtube,
       'terminal-video': terminalVideo,
+      tweet,
+      youtube,
       'video-link': videoLink,
       // 'svg-animation': svgAnimation,
     },
@@ -121,8 +123,9 @@ export const getMarkdocCustomConfig = (
     SideBySide,
     Tab,
     Tabs,
-    YouTube,
     TerminalVideo,
+    Tweet,
+    YouTube,
     VideoLink,
     // SvgAnimation,
   },
@@ -133,11 +136,21 @@ const tokenizer = new Tokenizer({
   allowComments: true,
 });
 
-export const parseMarkdown: (markdown: string) => Node = (markdown) => {
+const parseMarkdown: (markdown: string) => Node = (markdown) => {
   const tokens = tokenizer.tokenize(markdown);
   return parse(tokens);
 };
 
+export const extractFrontmatter = (
+  documentContent: string
+): Record<string, any> => {
+  const ast = parseMarkdown(documentContent);
+  const frontmatter = ast.attributes['frontmatter']
+    ? (yamlLoad(ast.attributes['frontmatter']) as Record<string, any>)
+    : {};
+  return frontmatter;
+};
+
 export const renderMarkdown: (
   documentContent: string,
   options: { filePath: string }
diff --git a/nx-dev/ui-markdoc/src/lib/nodes/helpers/transform-image-path.ts b/nx-dev/ui-markdoc/src/lib/nodes/helpers/transform-image-path.ts
index 70c0b67334..3bc0ce0af4 100644
--- a/nx-dev/ui-markdoc/src/lib/nodes/helpers/transform-image-path.ts
+++ b/nx-dev/ui-markdoc/src/lib/nodes/helpers/transform-image-path.ts
@@ -7,7 +7,7 @@ export function transformImagePath(
   return (src) => {
     const isRelative = src.startsWith('.');
 
-    if (!/\.(gif|jpe?g|tiff?|png|webp|bmp|svg)$/i.test(src)) {
+    if (!/\.(gif|jpe?g|tiff?|png|webp|bmp|svg|avif)$/i.test(src)) {
       return uriTransformer(src);
     }
 
diff --git a/package.json b/package.json
index 306588ecfa..d235527cd5 100644
--- a/package.json
+++ b/package.json
@@ -351,7 +351,7 @@
     "string-width": "^4.2.3",
     "strong-log-transformer": "^2.1.0",
     "tailwind-merge": "^1.8.1",
-    "tailwindcss": "3.2.4",
+    "tailwindcss": "3.4.3",
     "tslib": "^2.3.0",
     "weak-napi": "^2.0.2",
     "webpack-cli": "^5.1.4"
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index bde5f00b43..ce7b3ee4d3 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -32,16 +32,16 @@ dependencies:
     version: 0.5.3
   '@tailwindcss/aspect-ratio':
     specifier: ^0.4.2
-    version: 0.4.2(tailwindcss@3.2.4)
+    version: 0.4.2(tailwindcss@3.4.3)
   '@tailwindcss/forms':
     specifier: ^0.5.3
-    version: 0.5.3(tailwindcss@3.2.4)
+    version: 0.5.3(tailwindcss@3.4.3)
   '@tailwindcss/line-clamp':
     specifier: ^0.4.2
-    version: 0.4.2(tailwindcss@3.2.4)
+    version: 0.4.2(tailwindcss@3.4.3)
   '@tailwindcss/typography':
     specifier: ^0.5.7
-    version: 0.5.7(tailwindcss@3.2.4)
+    version: 0.5.7(tailwindcss@3.4.3)
   '@types/license-checker':
     specifier: ^25.0.3
     version: 25.0.3
@@ -139,8 +139,8 @@ dependencies:
     specifier: ^1.8.1
     version: 1.8.1
   tailwindcss:
-    specifier: 3.2.4
-    version: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+    specifier: 3.4.3
+    version: 3.4.3(ts-node@10.9.1)
   tslib:
     specifier: ^2.3.0
     version: 2.4.0
@@ -160,7 +160,7 @@ devDependencies:
     version: 0.1703.0
   '@angular-devkit/build-angular':
     specifier: ~17.3.0
-    version: 17.3.0(@angular/compiler-cli@17.3.0)(@swc/core@1.3.86)(@types/express@4.17.14)(@types/node@18.19.8)(html-webpack-plugin@5.5.0)(jest-environment-jsdom@29.4.3)(jest@29.4.3)(ng-packagr@17.3.0)(stylus@0.59.0)(tailwindcss@3.2.4)(typescript@5.4.2)(webpack-cli@5.1.4)
+    version: 17.3.0(@angular/compiler-cli@17.3.0)(@swc/core@1.3.86)(@types/express@4.17.14)(@types/node@18.19.8)(html-webpack-plugin@5.5.0)(jest-environment-jsdom@29.4.3)(jest@29.4.3)(ng-packagr@17.3.0)(stylus@0.59.0)(tailwindcss@3.4.3)(typescript@5.4.2)
   '@angular-devkit/core':
     specifier: ~17.3.0
     version: 17.3.0
@@ -760,7 +760,7 @@ devDependencies:
     version: 3.1.29(@next/env@14.0.4)(next@14.0.4)
   ng-packagr:
     specifier: ~17.3.0
-    version: 17.3.0(@angular/compiler-cli@17.3.0)(tailwindcss@3.2.4)(tslib@2.4.0)(typescript@5.4.2)
+    version: 17.3.0(@angular/compiler-cli@17.3.0)(tailwindcss@3.4.3)(tslib@2.4.0)(typescript@5.4.2)
   node-fetch:
     specifier: ^2.6.7
     version: 2.6.7
@@ -1139,6 +1139,10 @@ packages:
       '@algolia/requester-common': 4.22.1
     dev: false
 
+  /@alloc/quick-lru@5.2.0:
+    resolution: {integrity: sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw==}
+    engines: {node: '>=10'}
+
   /@ampproject/remapping@2.2.1:
     resolution: {integrity: sha512-lFMjJTrFL3j7L9yBxwYfCq2k6qqwHyzuUl/XBnif78PWTJYyL/dfowQHWE3sp6U6ZzqWiiIZnpTMO96zhkjwtg==}
     engines: {node: '>=6.0.0'}
@@ -1164,7 +1168,7 @@ packages:
       - chokidar
     dev: true
 
-  /@angular-devkit/build-angular@17.3.0(@angular/compiler-cli@17.3.0)(@swc/core@1.3.86)(@types/express@4.17.14)(@types/node@18.19.8)(html-webpack-plugin@5.5.0)(jest-environment-jsdom@29.4.3)(jest@29.4.3)(ng-packagr@17.3.0)(stylus@0.59.0)(tailwindcss@3.2.4)(typescript@5.4.2)(webpack-cli@5.1.4):
+  /@angular-devkit/build-angular@17.3.0(@angular/compiler-cli@17.3.0)(@swc/core@1.3.86)(@types/express@4.17.14)(@types/node@18.19.8)(html-webpack-plugin@5.5.0)(jest-environment-jsdom@29.4.3)(jest@29.4.3)(ng-packagr@17.3.0)(stylus@0.59.0)(tailwindcss@3.4.3)(typescript@5.4.2):
     resolution: {integrity: sha512-mC70mZK/liITM4VlGL6hmYPkVsZwAb+X3TxwodBl/g8p/sYijDhK/4QJHzmcHTxLYQQS6nS5CUcr9ARQFkGN2w==}
     engines: {node: ^18.13.0 || >=20.9.0, npm: ^6.11.0 || ^7.5.6 || >=8.0.0, yarn: '>= 1.13.0'}
     peerDependencies:
@@ -1246,7 +1250,7 @@ packages:
       magic-string: 0.30.8
       mini-css-extract-plugin: 2.8.1(webpack@5.90.3)
       mrmime: 2.0.0
-      ng-packagr: 17.3.0(@angular/compiler-cli@17.3.0)(tailwindcss@3.2.4)(tslib@2.4.0)(typescript@5.4.2)
+      ng-packagr: 17.3.0(@angular/compiler-cli@17.3.0)(tailwindcss@3.4.3)(tslib@2.4.0)(typescript@5.4.2)
       open: 8.4.2
       ora: 5.4.1
       parse5-html-rewriting-stream: 7.0.0
@@ -1261,7 +1265,7 @@ packages:
       semver: 7.6.0
       source-map-loader: 5.0.0(webpack@5.90.3)
       source-map-support: 0.5.21
-      tailwindcss: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+      tailwindcss: 3.4.3(ts-node@10.9.1)
       terser: 5.29.1
       tree-kill: 1.2.2
       tslib: 2.6.2
@@ -6597,7 +6601,6 @@ packages:
       strip-ansi-cjs: /strip-ansi@6.0.1
       wrap-ansi: 8.1.0
       wrap-ansi-cjs: /wrap-ansi@7.0.0
-    dev: true
 
   /@istanbuljs/load-nyc-config@1.1.0:
     resolution: {integrity: sha512-VjeHSlIzpv/NyD3N0YuHfXOPDIixcA1q2ZV98wsMqcYlPmv2n3Yb2lYP9XMElnaFVXg5A7YLTeLu6V84uQDjmQ==}
@@ -6915,7 +6918,6 @@ packages:
       '@jridgewell/set-array': 1.2.1
       '@jridgewell/sourcemap-codec': 1.4.15
       '@jridgewell/trace-mapping': 0.3.25
-    dev: true
 
   /@jridgewell/resolve-uri@3.1.0:
     resolution: {integrity: sha512-F2msla3tad+Mfht5cJq7LSXcdudKTWCVYUgw6pLFOOHSTtZlj6SWNYAp+AhuqLmWdBO2X5hPrLcu8cVP8fy28w==}
@@ -6933,12 +6935,11 @@ packages:
   /@jridgewell/set-array@1.2.1:
     resolution: {integrity: sha512-R8gLRTZeyp03ymzP/6Lil/28tGeGEzhx1q2k703KGWRAI1VdvPIXdG70VJc2pAMw3NA6JKL5hhFu1sJX0Mnn/A==}
     engines: {node: '>=6.0.0'}
-    dev: true
 
   /@jridgewell/source-map@0.3.3:
     resolution: {integrity: sha512-b+fsZXeLYi9fEULmfBrhxn4IrPlINf8fiNarzTof004v3lFdntdwa9PF7vFJqm3mg7s+ScJMxXaE3Acp1irZcg==}
     dependencies:
-      '@jridgewell/gen-mapping': 0.3.3
+      '@jridgewell/gen-mapping': 0.3.5
       '@jridgewell/trace-mapping': 0.3.21
 
   /@jridgewell/sourcemap-codec@1.4.14:
@@ -6966,7 +6967,6 @@ packages:
     dependencies:
       '@jridgewell/resolve-uri': 3.1.1
       '@jridgewell/sourcemap-codec': 1.4.15
-    dev: true
 
   /@jridgewell/trace-mapping@0.3.9:
     resolution: {integrity: sha512-3Belt6tdc8bPgAtbcmdtNJlirVoTmEb5e2gC94PnkwEW9jI6CAHUeoG85tjWP5WquqfavoMtMwiG4P926ZKKuQ==}
@@ -8352,7 +8352,7 @@ packages:
       esbuild:
         optional: true
     dependencies:
-      '@angular-devkit/build-angular': 17.3.0(@angular/compiler-cli@17.3.0)(@swc/core@1.3.86)(@types/express@4.17.14)(@types/node@18.19.8)(html-webpack-plugin@5.5.0)(jest-environment-jsdom@29.4.3)(jest@29.4.3)(ng-packagr@17.3.0)(stylus@0.59.0)(tailwindcss@3.2.4)(typescript@5.4.2)(webpack-cli@5.1.4)
+      '@angular-devkit/build-angular': 17.3.0(@angular/compiler-cli@17.3.0)(@swc/core@1.3.86)(@types/express@4.17.14)(@types/node@18.19.8)(html-webpack-plugin@5.5.0)(jest-environment-jsdom@29.4.3)(jest@29.4.3)(ng-packagr@17.3.0)(stylus@0.59.0)(tailwindcss@3.4.3)(typescript@5.4.2)
       '@angular-devkit/core': 17.3.0
       '@angular-devkit/schematics': 17.3.0
       '@nrwl/angular': 19.0.0-beta.7(@angular-devkit/build-angular@17.3.0)(@angular-devkit/core@17.3.0)(@angular-devkit/schematics@17.3.0)(@schematics/angular@17.3.0)(@swc-node/register@1.8.0)(@swc/core@1.3.86)(@types/node@18.19.8)(esbuild@0.19.5)(eslint@8.57.0)(html-webpack-plugin@5.5.0)(js-yaml@4.1.0)(nx@19.0.0-beta.7)(rxjs@7.8.1)(typescript@5.4.2)(verdaccio@5.15.4)(webpack-cli@5.1.4)
@@ -9605,7 +9605,6 @@ packages:
     resolution: {integrity: sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==}
     engines: {node: '>=14'}
     requiresBuild: true
-    dev: true
     optional: true
 
   /@pkgr/utils@2.3.1:
@@ -12607,32 +12606,32 @@ packages:
       defer-to-connect: 2.0.1
     dev: true
 
-  /@tailwindcss/aspect-ratio@0.4.2(tailwindcss@3.2.4):
+  /@tailwindcss/aspect-ratio@0.4.2(tailwindcss@3.4.3):
     resolution: {integrity: sha512-8QPrypskfBa7QIMuKHg2TA7BqES6vhBrDLOv8Unb6FcFyd3TjKbc6lcmb9UPQHxfl24sXoJ41ux/H7qQQvfaSQ==}
     peerDependencies:
       tailwindcss: '>=2.0.0 || >=3.0.0 || >=3.0.0-alpha.1'
     dependencies:
-      tailwindcss: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+      tailwindcss: 3.4.3(ts-node@10.9.1)
     dev: false
 
-  /@tailwindcss/forms@0.5.3(tailwindcss@3.2.4):
+  /@tailwindcss/forms@0.5.3(tailwindcss@3.4.3):
     resolution: {integrity: sha512-y5mb86JUoiUgBjY/o6FJSFZSEttfb3Q5gllE4xoKjAAD+vBrnIhE4dViwUuow3va8mpH4s9jyUbUbrRGoRdc2Q==}
     peerDependencies:
       tailwindcss: '>=3.0.0 || >= 3.0.0-alpha.1'
     dependencies:
       mini-svg-data-uri: 1.4.4
-      tailwindcss: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+      tailwindcss: 3.4.3(ts-node@10.9.1)
     dev: false
 
-  /@tailwindcss/line-clamp@0.4.2(tailwindcss@3.2.4):
+  /@tailwindcss/line-clamp@0.4.2(tailwindcss@3.4.3):
     resolution: {integrity: sha512-HFzAQuqYCjyy/SX9sLGB1lroPzmcnWv1FHkIpmypte10hptf4oPUfucryMKovZh2u0uiS9U5Ty3GghWfEJGwVw==}
     peerDependencies:
       tailwindcss: '>=2.0.0 || >=3.0.0 || >=3.0.0-alpha.1'
     dependencies:
-      tailwindcss: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+      tailwindcss: 3.4.3(ts-node@10.9.1)
     dev: false
 
-  /@tailwindcss/typography@0.5.7(tailwindcss@3.2.4):
+  /@tailwindcss/typography@0.5.7(tailwindcss@3.4.3):
     resolution: {integrity: sha512-JTTSTrgZfp6Ki4svhPA4mkd9nmQ/j9EfE7SbHJ1cLtthKkpW2OxsFXzSmxbhYbEkfNIyAyhle5p4SYyKRbz/jg==}
     peerDependencies:
       tailwindcss: '>=3.0.0 || insiders'
@@ -12641,7 +12640,7 @@ packages:
       lodash.isplainobject: 4.0.6
       lodash.merge: 4.6.2
       postcss-selector-parser: 6.0.10
-      tailwindcss: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+      tailwindcss: 3.4.3(ts-node@10.9.1)
     dev: false
 
   /@testing-library/dom@9.3.4:
@@ -14524,16 +14523,10 @@ packages:
       acorn: 8.11.3
     dev: true
 
-  /acorn-node@1.8.2:
-    resolution: {integrity: sha512-8mt+fslDufLYntIoPAaIMUe/lrbrehIiwmR3t2k9LljIzoigEPF27eLk2hy8zSGzmR/ogr7zbRKINMo1u0yh5A==}
-    dependencies:
-      acorn: 7.4.1
-      acorn-walk: 7.2.0
-      xtend: 4.0.2
-
   /acorn-walk@7.2.0:
     resolution: {integrity: sha512-OPdCF6GsMIP+Az+aWfAAOEt2/+iVDKE7oy6lJ098aoe59oAmK76qV6Gw60SbZ8jHuG2wH058GF4pLFbYamYrVA==}
     engines: {node: '>=0.4.0'}
+    dev: true
 
   /acorn-walk@8.2.0:
     resolution: {integrity: sha512-k+iyHEuPgSw6SbuDpGQM+06HQUa04DZ3o+F6CSzXMvvI5KMvnaEqXe+YVe555R9nn6GPt404fos4wcgpw12SDA==}
@@ -14548,6 +14541,7 @@ packages:
     resolution: {integrity: sha512-nQyp0o1/mNdbTO1PO6kHkwSrmgZ0MT/jCCpNiwbUjGoRN4dlBhqJtoQuCnEOKzgTVwg0ZWiCoQy6SxMebQVh8A==}
     engines: {node: '>=0.4.0'}
     hasBin: true
+    dev: true
 
   /acorn@8.11.3:
     resolution: {integrity: sha512-Y9rRfJG5jcKOE0CLisYbojUjIrIEE7AGMzA/Sm4BslANhbS+cDMpgBdcPT91oJ7OuJ9hYJBx59RjbhxVnrF8Xg==}
@@ -14756,7 +14750,6 @@ packages:
   /ansi-regex@6.0.1:
     resolution: {integrity: sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==}
     engines: {node: '>=12'}
-    dev: true
 
   /ansi-sequence-parser@1.1.0:
     resolution: {integrity: sha512-lEm8mt52to2fT8GhciPCGeCXACSz2UwIN4X2e2LJSnZ5uAbn2/dsYdOmUXq0AtWS5cpAupysIneExOgH0Vd2TQ==}
@@ -14782,11 +14775,9 @@ packages:
   /ansi-styles@6.2.1:
     resolution: {integrity: sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==}
     engines: {node: '>=12'}
-    dev: true
 
   /any-promise@1.3.0:
     resolution: {integrity: sha512-7UvmKalWRt1wgjL1RrGxoSJW/0QZFIegpeGvZG9kjp8vrRu55XTHbwnqq2GpXm9uLbcuhxm3IqX9OB4MZR1b2A==}
-    dev: false
 
   /anymatch@3.1.3:
     resolution: {integrity: sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==}
@@ -15815,7 +15806,6 @@ packages:
     resolution: {integrity: sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==}
     dependencies:
       balanced-match: 1.0.2
-    dev: true
 
   /braces@3.0.2:
     resolution: {integrity: sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==}
@@ -16597,7 +16587,6 @@ packages:
   /commander@4.1.1:
     resolution: {integrity: sha512-NOKm8xhkzAjzFx8B2v5OAHT+u5pRQc2UCa2Vq9jYL/31o2wi9mxBA7LIFs3sV5VSC49z6pEhfbMULvShKj26WA==}
     engines: {node: '>= 6'}
-    dev: true
 
   /commander@6.2.1:
     resolution: {integrity: sha512-U7VdrJFnJgo4xjrHpTzu0yrHPGImdsmD95ZlgYSEajAn2JKzDhDTPG9kBTefmObL2w/ngeZnilk+OV9CG3d7UA==}
@@ -17931,9 +17920,6 @@ packages:
       object-keys: 1.1.1
     dev: true
 
-  /defined@1.0.1:
-    resolution: {integrity: sha512-hsBd2qSVCRE+5PmNdHt1uzyrFu5d3RwmFDKzyNZMFq/EwDNJF7Ee5+D5oEKF0hU6LhtoUF1macFvOe4AskQC1Q==}
-
   /defu@6.1.4:
     resolution: {integrity: sha512-mEQCMmwJu317oSz8CwdIOdwf3xMif1ttiM8LTufzc3g6kR+9Pe236twL8j3IYT1F7GfRgGcW6MWxzZjLIkuHIg==}
     dev: true
@@ -18029,15 +18015,6 @@ packages:
       - supports-color
     dev: true
 
-  /detective@5.2.1:
-    resolution: {integrity: sha512-v9XE1zRnz1wRtgurGu0Bs8uHKFSTdteYZNbIPFVhUZ39L/S79ppMpdmVOZAnoz1jfEFodc48n6MX483Xo3t1yw==}
-    engines: {node: '>=0.8.0'}
-    hasBin: true
-    dependencies:
-      acorn-node: 1.8.2
-      defined: 1.0.1
-      minimist: 1.2.8
-
   /devalue@4.3.2:
     resolution: {integrity: sha512-KqFl6pOgOW+Y6wJgu80rHpo2/3H07vr8ntR9rkkFIRETewbf5GaYYcakYfiKz89K+sLsuPkQIZaXDMjUObZwWg==}
     dev: true
@@ -18236,7 +18213,6 @@ packages:
 
   /eastasianwidth@0.2.0:
     resolution: {integrity: sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==}
-    dev: true
 
   /ecc-jsbn@0.1.2:
     resolution: {integrity: sha512-eh9O+hwRHNbG4BLTjEl3nw044CkGm5X6LoaCf7LPp7UU8Qrt47JYNi6nPX8xjW97TKGKm1ouctg0QSpZe9qrnw==}
@@ -18290,7 +18266,6 @@ packages:
 
   /emoji-regex@9.2.2:
     resolution: {integrity: sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==}
-    dev: true
 
   /emojis-list@3.0.0:
     resolution: {integrity: sha512-/kyM18EfinwXZbno9FyUGeFh87KC8HRQBQGildHZbEuRyWFOmv1U10o9BBp8XVZDVNNuQKyIGIu5ZYAAXJ0V2Q==}
@@ -19692,6 +19667,7 @@ packages:
       glob-parent: 5.1.2
       merge2: 1.4.1
       micromatch: 4.0.5
+    dev: true
 
   /fast-glob@3.2.7:
     resolution: {integrity: sha512-rYGMRwip6lUMvYD3BTScMwT1HtAs2d71SMv66Vrxs0IekGZEjhM0pcMfjQPnknBt2zeCwQMEupiN02ZP4DiT1Q==}
@@ -19712,7 +19688,6 @@ packages:
       glob-parent: 5.1.2
       merge2: 1.4.1
       micromatch: 4.0.5
-    dev: true
 
   /fast-json-parse@1.0.3:
     resolution: {integrity: sha512-FRWsaZRWEJ1ESVNbDWmsAlqDk96gPQezzLghafp5J4GUKjbCz3OkAHuZs5TuPEtkbVQERysLp9xv6c24fBm8Aw==}
@@ -19996,7 +19971,6 @@ packages:
     dependencies:
       cross-spawn: 7.0.3
       signal-exit: 4.1.0
-    dev: true
 
   /forever-agent@0.6.1:
     resolution: {integrity: sha512-j0KLYPhm6zeac4lz3oJ3o65qvgQCcPubiyotZrXqEaG4hNagNYO8qdlUrX5vwqv9ohqeT/Z3j6+yW067yWWdUw==}
@@ -20563,6 +20537,17 @@ packages:
       path-scurry: 1.7.0
     dev: true
 
+  /glob@10.3.12:
+    resolution: {integrity: sha512-TCNv8vJ+xz4QiqTpfOJA7HvYv+tNIRHKfUWw/q+v2jdgN4ebz+KY9tGx5J4rHP0o84mNP+ApH66HRX8us3Khqg==}
+    engines: {node: '>=16 || 14 >=14.17'}
+    hasBin: true
+    dependencies:
+      foreground-child: 3.1.1
+      jackspeak: 2.3.6
+      minimatch: 9.0.3
+      minipass: 7.0.4
+      path-scurry: 1.10.2
+
   /glob@6.0.4:
     resolution: {integrity: sha512-MKZeRNyYZAVVVG1oZeLaWie1uweH40m9AZwIwxyPbTSX4hHrVYSzLg0Ro5Z5R7XKkIX+Cc6oD1rqeDJnwsB8/A==}
     dependencies:
@@ -20874,6 +20859,7 @@ packages:
     engines: {node: '>= 0.4.0'}
     dependencies:
       function-bind: 1.1.2
+    dev: true
 
   /hash-sum@2.0.0:
     resolution: {integrity: sha512-WdZTbAByD+pHfl/g9QSsBIIwy8IT+EsPiKDs0KNX+zSHhdDLFKdZu0BQHljvO+0QI/BasbMSUa8wYNCZTvhslg==}
@@ -21727,6 +21713,7 @@ packages:
     resolution: {integrity: sha512-RRjxlvLDkD1YJwDbroBHMb+cukurkDWNyHx7D3oNB5x9rb5ogcksMC5wHCadcXoo67gVr/+3GFySh3134zi6rw==}
     dependencies:
       has: 1.0.3
+    dev: true
 
   /is-core-module@2.13.0:
     resolution: {integrity: sha512-Z7dk6Qo8pOCp3l4tsX2C5ZVas4V+UxwQodwZhLopL91TX8UyyHEXafPcyoeeWuLrwzHcr3igO78wNLwHJHsMCQ==}
@@ -22195,6 +22182,14 @@ packages:
       '@pkgjs/parseargs': 0.11.0
     dev: true
 
+  /jackspeak@2.3.6:
+    resolution: {integrity: sha512-N3yCS/NegsOBokc8GAdM8UcmfsKiSS8cipheD/nivzr700H+nsMOxJjQnvwOcRYVuFkdH0wGUvW2WbXGmrZGbQ==}
+    engines: {node: '>=14'}
+    dependencies:
+      '@isaacs/cliui': 8.0.2
+    optionalDependencies:
+      '@pkgjs/parseargs': 0.11.0
+
   /jake@10.8.5:
     resolution: {integrity: sha512-sVpxYeuAhWt0OTWITwT98oyV0GsXyMlXCF+3L1SuafBVUIr/uILGRB+NqwkzhgXKvoJpDIpQvqkUALgdmQsQxw==}
     engines: {node: '>=10'}
@@ -22725,7 +22720,6 @@ packages:
   /jiti@1.21.0:
     resolution: {integrity: sha512-gFqAIbuKyyso/3G2qhiO2OM6shY6EPP/R0+mkDbyspxKazh8BXDC5FiFsUjlczgdNz/vfra0da2y+aHrusLG/Q==}
     hasBin: true
-    dev: true
 
   /js-tokens@4.0.0:
     resolution: {integrity: sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==}
@@ -23260,10 +23254,6 @@ packages:
       webpack-sources: 3.2.3
     dev: true
 
-  /lilconfig@2.0.6:
-    resolution: {integrity: sha512-9JROoBW7pobfsx+Sq2JsASvCo6Pfo6WWoUW79HuB1BCoBXD4PLWJPqDF6fNj67pqBYTbAHkE57M1kS/+L1neOg==}
-    engines: {node: '>=10'}
-
   /lilconfig@2.1.0:
     resolution: {integrity: sha512-utWOt/GHzuUxnLKxB6dk81RoOeoNeHgbrXiuGk4yyF5qlRz+iIVWu56E2fqGHFrXz0QNUhLB/8nKqvRH66JKGQ==}
     engines: {node: '>=10'}
@@ -23271,11 +23261,9 @@ packages:
   /lilconfig@3.0.0:
     resolution: {integrity: sha512-K2U4W2Ff5ibV7j7ydLr+zLAkIg5JJ4lPn1Ltsdt+Tz/IjQ8buJ55pZAxoP34lqIiwtF9iAvtLv3JGv7CAyAg+g==}
     engines: {node: '>=14'}
-    dev: true
 
   /lines-and-columns@1.2.4:
     resolution: {integrity: sha512-7ylylesZQ/PV29jhEDl3Ufjo6ZX7gCqJr5F7PKrqc93v7fzSymt1BpwEU8nAUXs8qzzvqhbjhK5QZg6Mt/HkBg==}
-    dev: true
 
   /lines-and-columns@2.0.3:
     resolution: {integrity: sha512-cNOjgCnLB+FnvWWtyRTzmB3POJ+cXxTA81LoW7u8JdmhfXzriropYwpjShnz1QLLWsQwY7nIxoDmcPTwphDK9w==}
@@ -23558,7 +23546,6 @@ packages:
   /lru-cache@10.2.0:
     resolution: {integrity: sha512-2bIM8x+VAf6JT4bKAljS1qUWgMsqZRPGJS6FSahIMPVvctcNhyVp7AJu7quxOW9jwkryBReKZY5tY5JYv2n/7Q==}
     engines: {node: 14 || >=16.14}
-    dev: true
 
   /lru-cache@4.1.5:
     resolution: {integrity: sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==}
@@ -24633,7 +24620,6 @@ packages:
     engines: {node: '>=16 || 14 >=14.17'}
     dependencies:
       brace-expansion: 2.0.1
-    dev: true
 
   /minimist-options@4.1.0:
     resolution: {integrity: sha512-Q4r8ghd80yhO/0j1O3B2BjweX3fiHg9cdOwjJd2J76Q135c+NDxGCqdYKQ1SKBuFfgWbAUzBfvYjPUEeNgqN1A==}
@@ -24729,6 +24715,10 @@ packages:
     engines: {node: '>=16 || 14 >=14.17'}
     dev: true
 
+  /minipass@7.0.4:
+    resolution: {integrity: sha512-jYofLM5Dam9279rdkWzqHozUo4ybjdZmCsDHePy5V/PbBcVMiSZR97gmAy45aqi8CK1lG2ECd356FU86avfwUQ==}
+    engines: {node: '>=16 || 14 >=14.17'}
+
   /minizlib@2.1.2:
     resolution: {integrity: sha512-bAxsR8BVfj60DWXHE3u30oHzfl4G7khkSuPW+qvpd7jFRHm7dLxOjUk1EHACJ/hxLY8phGJ0YhYHZo7jil7Qdg==}
     engines: {node: '>= 8'}
@@ -24857,12 +24847,12 @@ packages:
       any-promise: 1.3.0
       object-assign: 4.1.1
       thenify-all: 1.6.0
-    dev: false
 
   /nanoid@3.3.6:
     resolution: {integrity: sha512-BGcqMMJuToF7i1rt+2PWSNVnWIkGCU78jBG3RxO/bZlnZPK2Cmi2QaffxGO/2RvWi9sL+FAiRiXMgsyxQ1DIDA==}
     engines: {node: ^10 || ^12 || ^13.7 || ^14 || >=15.0.1}
     hasBin: true
+    dev: true
 
   /nanoid@3.3.7:
     resolution: {integrity: sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==}
@@ -24975,7 +24965,7 @@ packages:
       - '@babel/core'
       - babel-plugin-macros
 
-  /ng-packagr@17.3.0(@angular/compiler-cli@17.3.0)(tailwindcss@3.2.4)(tslib@2.4.0)(typescript@5.4.2):
+  /ng-packagr@17.3.0(@angular/compiler-cli@17.3.0)(tailwindcss@3.4.3)(tslib@2.4.0)(typescript@5.4.2):
     resolution: {integrity: sha512-kMSqxeDgv88SWCoapWNRRN1UdBgwu9/Pw/j7u2WFGmzrIWUFivNWBBSSL94kMxr2La+Z9wMwiL8EwKNvmCpg2A==}
     engines: {node: ^18.13.0 || >=20.9.0}
     hasBin: true
@@ -25011,7 +25001,7 @@ packages:
       postcss: 8.4.35
       rxjs: 7.8.1
       sass: 1.70.0
-      tailwindcss: 3.2.4(postcss@8.4.19)(ts-node@10.9.1)
+      tailwindcss: 3.4.3(ts-node@10.9.1)
       tslib: 2.4.0
       typescript: 5.4.2
     optionalDependencies:
@@ -26370,6 +26360,13 @@ packages:
   /path-parse@1.0.7:
     resolution: {integrity: sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==}
 
+  /path-scurry@1.10.2:
+    resolution: {integrity: sha512-7xTavNy5RQXnsjANvVvMkEjvloOinkAjv/Z6Ildz9v2RinZ4SBKTWFOVRbaF8p0vpHnyjV/UwNDdKuUv6M5qcA==}
+    engines: {node: '>=16 || 14 >=14.17'}
+    dependencies:
+      lru-cache: 10.2.0
+      minipass: 7.0.4
+
   /path-scurry@1.7.0:
     resolution: {integrity: sha512-UkZUeDjczjYRE495+9thsgcVgsaCPkaw80slmfVFgllxY+IO8ubTsOpFVjDPROBqJdHfVPUFRHPBV/WciOVfWg==}
     engines: {node: '>=16 || 14 >=14.17'}
@@ -26512,7 +26509,6 @@ packages:
   /pirates@4.0.6:
     resolution: {integrity: sha512-saLsH7WeYYPiD25LDuLRRY/i+6HaPYr6G1OUlN39otzkSTxKnubR9RTxS3/Kk50s1g2JTgFwWQDQyplC5/SHZg==}
     engines: {node: '>= 6'}
-    dev: true
 
   /piscina@4.4.0:
     resolution: {integrity: sha512-+AQduEJefrOApE4bV7KRmp3N2JnnyErlVqq4P/jmko4FPz9Z877BCccl/iB3FdrWSUkvbGV9Kan/KllJgat3Vg==}
@@ -26970,6 +26966,18 @@ packages:
       postcss-value-parser: 4.2.0
       read-cache: 1.0.0
       resolve: 1.22.1
+    dev: true
+
+  /postcss-import@15.1.0(postcss@8.4.35):
+    resolution: {integrity: sha512-hpr+J05B2FVYUAXHeK1YyI267J/dDDhMU6B6civm8hSY1jYJnBXxzKDKDswzJmtLHryrjhnDjqqp/49t8FALew==}
+    engines: {node: '>=14.0.0'}
+    peerDependencies:
+      postcss: ^8.0.0
+    dependencies:
+      postcss: 8.4.35
+      postcss-value-parser: 4.2.0
+      read-cache: 1.0.0
+      resolve: 1.22.8
 
   /postcss-initial@4.0.1(postcss@8.4.19):
     resolution: {integrity: sha512-0ueD7rPqX8Pn1xJIjay0AZeIuDoF+V+VvMt/uOnn+4ezUKhZM/NokDeP6DwMNyIoYByuN/94IQnt5FEkaN59xQ==}
@@ -26979,14 +26987,14 @@ packages:
       postcss: 8.4.19
     dev: true
 
-  /postcss-js@4.0.0(postcss@8.4.19):
-    resolution: {integrity: sha512-77QESFBwgX4irogGVPgQ5s07vLvFqWr228qZY+w6lW599cRlK/HmnlivnnVUxkjHnCu4J16PDMHcH+e+2HbvTQ==}
+  /postcss-js@4.0.1(postcss@8.4.35):
+    resolution: {integrity: sha512-dDLF8pEO191hJMtlHFPRa8xsizHaM82MLfNkUHdUtVEV3tgTp5oj+8qbEqYM57SLfc74KSbw//4SeJma2LRVIw==}
     engines: {node: ^12 || ^14 || >= 16}
     peerDependencies:
-      postcss: ^8.3.3
+      postcss: ^8.4.21
     dependencies:
       camelcase-css: 2.0.1
-      postcss: 8.4.19
+      postcss: 8.4.35
 
   /postcss-lab-function@4.2.1(postcss@8.4.19):
     resolution: {integrity: sha512-xuXll4isR03CrQsmxyz92LJB2xX9n+pZJ5jE9JgcnmsCammLyKdlzrBin+25dy6wIjfhJpKBAN80gsTlCgRk2w==}
@@ -27015,6 +27023,7 @@ packages:
       postcss: 8.4.19
       ts-node: 10.9.1(@swc/core@1.3.86)(@types/node@18.19.8)(typescript@5.4.2)
       yaml: 1.10.2
+    dev: true
 
   /postcss-load-config@4.0.2(postcss@8.4.19)(ts-node@10.9.1):
     resolution: {integrity: sha512-bSVhyJGL00wMVoPUzAVAnbEoWyqRxkjv64tUl427SKnPrENtq6hJwUojroMz2VB+Q1edmi4IfrAPpami5VVgMQ==}
@@ -27034,6 +27043,23 @@ packages:
       yaml: 2.3.4
     dev: true
 
+  /postcss-load-config@4.0.2(postcss@8.4.35)(ts-node@10.9.1):
+    resolution: {integrity: sha512-bSVhyJGL00wMVoPUzAVAnbEoWyqRxkjv64tUl427SKnPrENtq6hJwUojroMz2VB+Q1edmi4IfrAPpami5VVgMQ==}
+    engines: {node: '>= 14'}
+    peerDependencies:
+      postcss: '>=8.0.9'
+      ts-node: '>=9.0.0'
+    peerDependenciesMeta:
+      postcss:
+        optional: true
+      ts-node:
+        optional: true
+    dependencies:
+      lilconfig: 3.0.0
+      postcss: 8.4.35
+      ts-node: 10.9.1(@swc/core@1.3.86)(@types/node@18.19.8)(typescript@5.4.2)
+      yaml: 2.3.4
+
   /postcss-loader@6.2.1(postcss@8.4.19)(webpack@5.88.0):
     resolution: {integrity: sha512-WbbYpmAaKcux/P66bZ40bpWsBucjx/TTgVVzRZ9yUO8yQfVBlameJ0ZGVaPfH64hNSBh63a+ICP5nqOpBA0w+Q==}
     engines: {node: '>= 12.13.0'}
@@ -27314,6 +27340,18 @@ packages:
       postcss: 8.4.35
     dev: true
 
+  /postcss-modules-local-by-default@4.0.3(postcss@8.4.19):
+    resolution: {integrity: sha512-2/u2zraspoACtrbFRnTijMiQtb4GW4BvatjaG/bCjYQo8kLTdevCUlwuBHx2sCnSyrI3x3qj4ZK1j5LQBgzmwA==}
+    engines: {node: ^10 || ^12 || >= 14}
+    peerDependencies:
+      postcss: ^8.1.0
+    dependencies:
+      icss-utils: 5.1.0(postcss@8.4.19)
+      postcss: 8.4.19
+      postcss-selector-parser: 6.0.15
+      postcss-value-parser: 4.2.0
+    dev: true
+
   /postcss-modules-local-by-default@4.0.4(postcss@8.4.19):
     resolution: {integrity: sha512-L4QzMnOdVwRm1Qb8m4x8jsZzKAaPAgrUF1r/hjDR2Xj7R+8Zsf97jAlSQzWtKx5YNiNGN8QxmPFIc/sh+RQl+Q==}
     engines: {node: ^10 || ^12 || >= 14}
@@ -27338,6 +27376,16 @@ packages:
       postcss-value-parser: 4.2.0
     dev: true
 
+  /postcss-modules-scope@3.0.0(postcss@8.4.19):
+    resolution: {integrity: sha512-hncihwFA2yPath8oZ15PZqvWGkWf+XUfQgUGamS4LqoP1anQLOsOJw0vr7J7IwLpoY9fatA2qiGUGmuZL0Iqlg==}
+    engines: {node: ^10 || ^12 || >= 14}
+    peerDependencies:
+      postcss: ^8.1.0
+    dependencies:
+      postcss: 8.4.19
+      postcss-selector-parser: 6.0.15
+    dev: true
+
   /postcss-modules-scope@3.1.1(postcss@8.4.19):
     resolution: {integrity: sha512-uZgqzdTleelWjzJY+Fhti6F3C9iF1JR/dODLs/JDefozYcKTBCdD8BIl6nNPbTbcLnGrk56hzwZC2DaGNvYjzA==}
     engines: {node: ^10 || ^12 || >= 14}
@@ -27410,13 +27458,13 @@ packages:
       string-hash: 1.1.3
     dev: true
 
-  /postcss-nested@6.0.0(postcss@8.4.19):
-    resolution: {integrity: sha512-0DkamqrPcmkBDsLn+vQDIrtkSbNkv5AD/M322ySo9kqFkCIYklym2xEmWkwo+Y3/qZo34tzEPNUw4y7yMCdv5w==}
+  /postcss-nested@6.0.1(postcss@8.4.35):
+    resolution: {integrity: sha512-mEp4xPMi5bSWiMbsgoPfcP74lsWLHkQbZc3sY+jWYd65CUwXrUaTp0fmNpa01ZcETKlIgUdFN/MpS2xZtqL9dQ==}
     engines: {node: '>=12.0'}
     peerDependencies:
       postcss: ^8.2.14
     dependencies:
-      postcss: 8.4.19
+      postcss: 8.4.35
       postcss-selector-parser: 6.0.15
 
   /postcss-nesting@10.1.10(postcss@8.4.19):
@@ -27919,13 +27967,6 @@ packages:
       util-deprecate: 1.0.2
     dev: false
 
-  /postcss-selector-parser@6.0.11:
-    resolution: {integrity: sha512-zbARubNdogI9j7WY4nQJBiNqQf3sLS3wCP4WfOidu+p28LofJqDH1tcXypGrcmMHhDk2t9wGhCsYe/+szLTy1g==}
-    engines: {node: '>=4'}
-    dependencies:
-      cssesc: 3.0.0
-      util-deprecate: 1.0.2
-
   /postcss-selector-parser@6.0.15:
     resolution: {integrity: sha512-rEYkQOMUCEMhsKbK66tbEU9QVIxbhN18YiniAwA7XQYTVBqrBy+P2p5JcdqsHgKM2zWylp8d7J6eszocfds5Sw==}
     engines: {node: '>=4'}
@@ -28019,6 +28060,7 @@ packages:
       nanoid: 3.3.6
       picocolors: 1.0.0
       source-map-js: 1.0.2
+    dev: true
 
   /postcss@8.4.23:
     resolution: {integrity: sha512-bQ3qMcpF6A/YjR55xtoTr0jGOlnPOKAIMdOWiv0EIT6HVPEaJiJB4NLljSbiHoC2RX7DN5Uvjtpbg1NPdwv1oA==}
@@ -28053,7 +28095,6 @@ packages:
       nanoid: 3.3.7
       picocolors: 1.0.0
       source-map-js: 1.0.2
-    dev: true
 
   /preact@10.6.4:
     resolution: {integrity: sha512-WyosM7pxGcndU8hY0OQlLd54tOU+qmG45QXj2dAYrL11HoyU/EzOSTlpJsirbBr1QW7lICxSsVJJmcmUglovHQ==}
@@ -28358,6 +28399,7 @@ packages:
   /quick-lru@5.1.1:
     resolution: {integrity: sha512-WuyALRjWPDGtt/wzJiadO5AXY+8hZ80hVpe6MyivgraREW751X3SbhRvG3eLKOYN+8VEvqLcf3wdnt44Z4S4SA==}
     engines: {node: '>=10'}
+    dev: true
 
   /radix3@1.1.0:
     resolution: {integrity: sha512-pNsHDxbGORSvuSScqNJ+3Km6QAVqk8CfsCBIEoDgpqLrkD2f3QM4I7d1ozJJ172OmIcoUcerZaNWqtLkRXTV3A==}
@@ -29172,6 +29214,7 @@ packages:
       is-core-module: 2.11.0
       path-parse: 1.0.7
       supports-preserve-symlinks-flag: 1.0.0
+    dev: true
 
   /resolve@1.22.8:
     resolution: {integrity: sha512-oKWePCxqpd6FlLvGV1VU0x7bkPmmCNolxzjMf4NczoDnQcIWrAF+cPtZn5i6n+RfD2d9i0tzpKnG6Yk168yIyw==}
@@ -29873,7 +29916,6 @@ packages:
   /signal-exit@4.1.0:
     resolution: {integrity: sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==}
     engines: {node: '>=14'}
-    dev: true
 
   /sigstore@2.2.1:
     resolution: {integrity: sha512-OBBSKvmjr4DCyUb+IC2p7wooOCsCNwaqvCilTJVNPo0y8lJl+LsCrfz4LtMwnw3Gn+8frt816wi1+DWZTUCpBQ==}
@@ -30374,7 +30416,6 @@ packages:
       eastasianwidth: 0.2.0
       emoji-regex: 9.2.2
       strip-ansi: 7.0.1
-    dev: true
 
   /string.prototype.matchall@4.0.8:
     resolution: {integrity: sha512-6zOCOcJ+RJAQshcTvXPHoxoQGONa3e/Lqx90wUA+wEzX78sg5Bo+1tQo4N0pohS0erG9qtCqJDjNCQBjeWVxyg==}
@@ -30458,7 +30499,6 @@ packages:
     engines: {node: '>=12'}
     dependencies:
       ansi-regex: 6.0.1
-    dev: true
 
   /strip-bom@3.0.0:
     resolution: {integrity: sha512-vavAMRXOgBVNF6nyEEmL3DBK19iRpDcoIwW+swQ+CbGiu7lju6t+JklA1MHweoWtadgt4ISVUsXLyDq34ddcwA==}
@@ -30668,6 +30708,19 @@ packages:
       - supports-color
     dev: true
 
+  /sucrase@3.35.0:
+    resolution: {integrity: sha512-8EbVDiu9iN/nESwxeSxDKe0dunta1GOlHufmSSXxMD2z2/tMZpDMpvXQGsc+ajGo8y2uYUmixaSRUc/QPoQ0GA==}
+    engines: {node: '>=16 || 14 >=14.17'}
+    hasBin: true
+    dependencies:
+      '@jridgewell/gen-mapping': 0.3.5
+      commander: 4.1.1
+      glob: 10.3.12
+      lines-and-columns: 1.2.4
+      mz: 2.7.0
+      pirates: 4.0.6
+      ts-interface-checker: 0.1.13
+
   /supports-color@5.5.0:
     resolution: {integrity: sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==}
     engines: {node: '>=4'}
@@ -30840,36 +30893,33 @@ packages:
     resolution: {integrity: sha512-+fflfPxvHFr81hTJpQ3MIwtqgvefHZFUHFiIHpVIRXvG/nX9+gu2P7JNlFu2bfDMJ+uHhi/pUgzaYacMoXv+Ww==}
     dev: false
 
-  /tailwindcss@3.2.4(postcss@8.4.19)(ts-node@10.9.1):
-    resolution: {integrity: sha512-AhwtHCKMtR71JgeYDaswmZXhPcW9iuI9Sp2LvZPo9upDZ7231ZJ7eA9RaURbhpXGVlrjX4cFNlB4ieTetEb7hQ==}
-    engines: {node: '>=12.13.0'}
+  /tailwindcss@3.4.3(ts-node@10.9.1):
+    resolution: {integrity: sha512-U7sxQk/n397Bmx4JHbJx/iSOOv5G+II3f1kpLpY2QeUv5DcPdcTsYLlusZfq1NthHS1c1cZoyFmmkex1rzke0A==}
+    engines: {node: '>=14.0.0'}
     hasBin: true
-    peerDependencies:
-      postcss: ^8.0.9
     dependencies:
+      '@alloc/quick-lru': 5.2.0
       arg: 5.0.2
       chokidar: 3.5.3
-      color-name: 1.1.4
-      detective: 5.2.1
       didyoumean: 1.2.2
       dlv: 1.1.3
-      fast-glob: 3.2.12
+      fast-glob: 3.3.2
       glob-parent: 6.0.2
       is-glob: 4.0.3
-      lilconfig: 2.0.6
+      jiti: 1.21.0
+      lilconfig: 2.1.0
       micromatch: 4.0.5
       normalize-path: 3.0.0
       object-hash: 3.0.0
       picocolors: 1.0.0
-      postcss: 8.4.19
-      postcss-import: 14.1.0(postcss@8.4.19)
-      postcss-js: 4.0.0(postcss@8.4.19)
-      postcss-load-config: 3.1.4(postcss@8.4.19)(ts-node@10.9.1)
-      postcss-nested: 6.0.0(postcss@8.4.19)
-      postcss-selector-parser: 6.0.11
-      postcss-value-parser: 4.2.0
-      quick-lru: 5.1.1
-      resolve: 1.22.1
+      postcss: 8.4.35
+      postcss-import: 15.1.0(postcss@8.4.35)
+      postcss-js: 4.0.1(postcss@8.4.35)
+      postcss-load-config: 4.0.2(postcss@8.4.35)(ts-node@10.9.1)
+      postcss-nested: 6.0.1(postcss@8.4.35)
+      postcss-selector-parser: 6.0.15
+      resolve: 1.22.8
+      sucrase: 3.35.0
     transitivePeerDependencies:
       - ts-node
 
@@ -31135,13 +31185,11 @@ packages:
     engines: {node: '>=0.8'}
     dependencies:
       thenify: 3.3.1
-    dev: false
 
   /thenify@3.3.1:
     resolution: {integrity: sha512-RVZSIV5IG10Hk3enotrhvz0T9em6cyHBLkH/YAZuKqd8hRkKhSfCGIcP2KUY0EPxndzANBmNllzWPwak+bheSw==}
     dependencies:
       any-promise: 1.3.0
-    dev: false
 
   /throat@5.0.0:
     resolution: {integrity: sha512-fcwX4mndzpLQKBS1DVYhGAcYaYt7vsHNIvQV+WXMvnow5cgjPphq5CaayLaGsjRdSCKZFNGt7/GYAuXaNOiYCA==}
@@ -31365,6 +31413,9 @@ packages:
     engines: {node: '>=6.10'}
     dev: true
 
+  /ts-interface-checker@0.1.13:
+    resolution: {integrity: sha512-Y/arvbn+rrz3JCKl9C4kVNfTfSm2/mEp5FSz5EsZSANGPSlQrpRI5M4PKF+mJnE52jOO90PnPSc3Ur3bTQw0gA==}
+
   /ts-jest@29.1.0(@babel/core@7.23.2)(@jest/types@29.6.3)(babel-jest@29.4.3)(esbuild@0.19.5)(jest@29.4.3)(typescript@5.4.2):
     resolution: {integrity: sha512-ZhNr7Z4PcYa+JjMl62ir+zPiNJfXJN6E8hSLnaUKhOgqcn8vb3e537cpkd0FuAfRK3sR1LSqM1MOhliXNgOFPA==}
     engines: {node: ^14.15.0 || ^16.10.0 || >=18.0.0}
@@ -33709,7 +33760,6 @@ packages:
       ansi-styles: 6.2.1
       string-width: 5.1.2
       strip-ansi: 7.0.1
-    dev: true
 
   /wrappy@1.0.2:
     resolution: {integrity: sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==}
@@ -33824,11 +33874,11 @@ packages:
   /yaml@1.10.2:
     resolution: {integrity: sha512-r3vXyErRCYJ7wg28yvBY5VSoAF8ZvlcW9/BwUzEtUsjvX/DKs24dIkuwjtuprwJJHsbyUbLApepYTR1BN4uHrg==}
     engines: {node: '>= 6'}
+    dev: true
 
   /yaml@2.3.4:
     resolution: {integrity: sha512-8aAvwVUSHpfEqTQ4w/KMlf3HcRdt50E5ODIQJBw1fQ5RL34xabzxtUlzTXVqc4rkZsPbvrXKWnABCD7kWSmocA==}
     engines: {node: '>= 14'}
-    dev: true
 
   /yargs-parser@20.2.9:
     resolution: {integrity: sha512-y11nGElTIV+CT3Zv9t7VKl+Q3hTQoT9a1Qzezhhl6Rp21gJ/IVTW7Z3y9EWXhuUBC2Shnf+DX0antecpAwSP8w==}
diff --git a/scripts/documentation/map-link-checker.ts b/scripts/documentation/map-link-checker.ts
index ec0d9da8d4..ce13e78be7 100644
--- a/scripts/documentation/map-link-checker.ts
+++ b/scripts/documentation/map-link-checker.ts
@@ -13,7 +13,7 @@ const basePath = 'docs';
 const sharedFilesPattern = 'shared/cli';
 
 const readmePathList: string[] = glob
-  .sync(`${basePath}/**/!(documents|changelog)/!(README).md`)
+  .sync(`${basePath}/**/!(blog|documents|changelog)/!(README).md`)
   .map((path: string) => path.split(basePath)[1])
   .map((path: string) => path.slice(1, -3)) // Removing first `/` and `.md`
   .filter((path: string) => !path.startsWith(sharedFilesPattern));
diff --git a/tsconfig.base.json b/tsconfig.base.json
index 5bb03a0d55..c0f0703281 100644
--- a/tsconfig.base.json
+++ b/tsconfig.base.json
@@ -87,6 +87,7 @@
       "@nx/nx-dev/models-document": ["nx-dev/models-document/src/index.ts"],
       "@nx/nx-dev/models-menu": ["nx-dev/models-menu/src/index.ts"],
       "@nx/nx-dev/models-package": ["nx-dev/models-package/src/index.ts"],
+      "@nx/nx-dev/ui-blog": ["nx-dev/ui-blog/src/index.ts"],
       "@nx/nx-dev/ui-commands": ["nx-dev/ui-commands/src/index.ts"],
       "@nx/nx-dev/ui-common": ["nx-dev/ui-common/src/index.ts"],
       "@nx/nx-dev/ui-community": ["nx-dev/ui-community/src/index.ts"],