Learn D3, Jest and Most

D3.js is a JavaScript library for manipulating documents based on data. D3 helps you bring data to life using HTML, SVG and CSS. D3’s emphasis on web standards gives you the full capabilities of modern browsers without tying yourself to a proprietary framework, combining powerful visualization components and a data-driven approach to DOM manipulation.

In this lesson, we'll clean up some of our placeholder elements. We'll then look at D3's ordinal scale to create a color scale that maps our regions to colors. We'll apply the colors based on region to our data points via the SVG `g`(group) element to apply the color to both our bars and their corresponding inline labels.

Create a Color Scale with D3's scaleOrdinal

Looking at our bars against each other with the x-axis as a guide gives us some relative information, but doesn't deliver the most precise values. In this lesson, we'll add additional labels to show the exact values of each data point in the context of the individual bars.

Clarify Data in D3 with Additional Labels and Rounded Domain Values

In this lesson, we'll see how we can add labels down the y-axis using our band scale. We'll see how to render the labels in React and how we can precisely position the labels based on values calculated by D3 and our scales.

Render a Y Axis for a Bar Chart with D3 and React

In this lesson, we'll take advantage of our `xScale` and the bottom margin to create an axis to start giving our data meaning. We'll access `ticks` from the scale and then use React to render and position the SVG `rect` and `text` elements to create the x-axis for our chart.

Render an X Axis for a Bar Chart with D3 and React

When applying scales to data elements in D3, it's common to combine the scale with an accessor function in order to apply the scale to the appropriate key on a data object. In this lesson, we'll create scaled accessors to refactor and tighten up some existing code.

Create Scaled Accessor Functions from D3 Scales

A band scale allows us to map a discrete set of values to a continuous range. In this lesson, we'll use a band scale in D3 to take the distinct "region" keys in our sample data and map those to evenly spaced and sized elements on our y-axis. We'll use this band scale to show a bar in the bar chart for each region, setting their size and position based on this scale.

Layout SVG Elements on a Y Axis with a D3 Band Scale in React

Drawing data accurately requires a consistent and precise mechanism for mapping data values to pixels on the screen. We can accomplish this mapping in D3 using scales. There are various scales available in D3, depending on your needs. In this lesson we'll using a linear scale to map a data domain of continuous values to continuous range of pixel values. We'll render a new SVG element, setting its width from our scale.

Set an SVG Element's Width Based on a D3 Linear Scale in React

When you want to add data visualizations to your web app, D3 is pretty much the accepted standard.

In this course, we'll start from scratch and build out a bar chart for some sample data using D3's utilities to wrangle the data and then we'll handle the rendering with React.

We'll start by laying out the SVG element that will hold everything, then we'll move on to creating scales that will give us the information we need to render our data as well as axes to give our data some meaning.

Along the way, we'll cover accessor functions, linear scales, band scales and finally, we'll use an ordinal scale to map data objects to colors.

This course certainly won't cover all of D3, but we'll cover enough of the fundamentals to give you a solid jumping off point for future D3 and React data visualization work.

Introduction to Create a Bar Chart with React and D3

jest

Jest is a fast and safe testing framework with a focus on simplicity. 
This lesson will walk you through how to add jest to your application by running `yarn add --dev jest` followed by updating your `package.json` to be able to run your tests on the console by using the `yarn test` script.
This lesson covers how to create your first test by creating your first block that groups several related tests with `describe` and then adding your first test method using either the `it` or `test` keyword.

Add Jest to Your Application and Create Your First Test

The pluggable linting utility for JavaScript and JSX.

eslint

We can leverage GitHub Actions to automate the running of all of our accessibility auditing tools as part of a Continuous Integration (CI) workflow. 

Auditing tools will only catch a percentage of potential accessibility issues, it is no replacement for manual testing.  But being able to automate the auditing will add efficiencies to our testing and provide an early warning system that can be run much more frequently than it’s practical to perform manual testing.  Additionally, we can use our CI suite as a safety net to prevent code changes that break accessibility from being able to be merged.

## Resources
* https://app.egghead.io/lessons/react-set-up-eslint-to-audit-accessibility-issues-in-react
* https://docs.cypress.io/guides/continuous-integration/github-actions#Basic-Setup
* https://github.com/cypress-io/github-action

Automate Accessibility Audits with GitHub Actions

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing
* the flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app
* A safety net for any accessibility regressions

Here we'll see how to use `jest-axe` with `react-testing-library` to render the components for `jest-axe` to audit for accessibility.

The React Testing Library is a very light-weight solution for testing React components. It provides light utility functions on top of react-dom and react-dom/test-utils, in a way that encourages better testing practices.

## Resources
* jest-axe: https://github.com/nickcolley/jest-axe
* react-testing-library: https://testing-library.com/docs/react-testing-library/intro/

Write Better Unit Tests with react-testing-library and jest-axe

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing.
* The flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app.
* A safety net for any accessibility regressions.

Here we'll see how to use `jest-axe` with `enzyme` to render the components for `jest-axe` to audit for accessibility.

Enzyme is a JavaScript Testing utility for React that makes it easier to test your React Components' output. You can also manipulate, traverse, and in some ways simulate runtime given the output.

## Resources
* jest-axe: https://github.com/nickcolley/jest-axe
* enzyme: https://enzymejs.github.io/enzyme

Write Unit Tests for Accessibility Using jest-axe and enzyme

We can add accessibility testing to our `jest` unit tests with `jest-axe` which gives us:

* An easy way to automate accessibility auditing.
* The flexibility to audit at any level of our code, as low as an element and as high as a component representing an entire page of our app.
* A safety net for any accessibility regressions.

Here we'll see how to use `jest-axe` with `ReactDOM` to render components for `jest-axe` to audit for accessibility.

## Resources
* https://github.com/nickcolley/jest-axe

Render Components with ReactDOM to Write Tests with Jest and jest-axe

Best practices for building & testing redux applications have changed dramatically over time. This course aims to be a comprehensive yet understandable resource for those seeking to improve the testing of their redux applications.

This course is broken up into three parts.

The intro is look at how to add jest to an existing react redux application that was built on top of [vite](https://vitejs.dev/). We cover basic functionality like [watch mode](https://jestjs.io/docs/cli#--watch) and generating and using [code coverage](https://jestjs.io/docs/cli#--coverageboolean) to inform our testing strategy.

The first section covers the specifics of unit testing the redux code in our application. We'll go over how to test reducers, selectors and thunks. As part of this we'll touch on mocking APIs and using [Redux Mock Store](https://github.com/reduxjs/redux-mock-store) as well as running actions through our applications' actual reducers to broaden our test coverage.

Finally we'll look at how we can test our redux connected react components using the various utilities that come with the [React Testing Library](https://testing-library.com/docs/react-testing-library/intro/). We'll cover simulating various kinds of user input with the [user-event module](https://testing-library.com/docs/ecosystem-user-event), populating our redux store with test data, using [jest spy](https://jestjs.io/docs/jest-object#jestspyonobject-methodname), how to wait for asynchronous tasks to complete, and several approaches for finding & asserting that visual elements exist on the page.

This course is built on top of content that was created for the [Modern Redux with RTK and TypeScript](https://app.egghead.io/playlists/modern-redux-with-redux-toolkit-rtk-and-typescript-64f243c8) course and I highly recommend you start there if you haven't completed it already. 

I'm confident you will level up your redux testing abilities if  watch these lessons and practice coding each of them as you go.

Intro to Confidently Testing Redux Applications with Jest & TypeScript

Intermission Pep Talk - Testing Redux Applications

The [reselect module](https://github.com/reduxjs/reselect) popularized a pattern of memoized redux selectors. Now that pattern is baked into Redux Toolkit with its [createSelector](https://redux-toolkit.js.org/api/createSelector) method, which is used by the `getMemoizedNumItems` selector we're testing here.

Any selectors created with `createSelector` come with these two additional methods `recomputations()` and `resetRecomputations()`. These methods keep track of how many teams your data was recomputed and are essential for testing these selectors.

Some additional examples on testing memoized selectors can be found here:
https://github.com/reduxjs/reselect#q-how-do-i-test-a-selector



----

The createSelector method first takes any number of "input selectors" which gather data from your redux store and then for its final arguments takes an additional selector which has for its inputs the result of those input selectors.

The memoization is broken if either the initial state is unchanged OR if the any of the  results of the input selectors are unchanged. It uses `===` equality and not any sort of nested equality checking so `state` and `{ ...state }` would not be considered the same and always would recompute. On the flip side passing in `state` and then running `state.count++` would not trigger a recompute automatically, because the `state` object reference has not changed and `===` would pass. It definitely tripped me up a few times, so keep an eye out for issues with this.




Unit Testing a Memoized Redux Selector Built with Reselect/RTK

Redux is a predictable state container for JavaScript apps.
It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test.

redux

There are several ways to mock APIs for our tests.

Here we're using [jest.mock](https://jestjs.io/docs/es6-class-mocks#calling-jestmock-with-the-module-factory-parameter) with the module factory parameter to a new mocked module to replace our original. This helps us avoid problems like servers taking a long time and node.js not having fetch built-in.

When using mocks this way it's important to note that this mocked module is only going to show up for the tests executed in this file. Other test suites will continue to receive the original implementation of app/api. 

Other approaches to mock APIs include mocking out `window.fetch` or using [Mock Service Worker](https://mswjs.io/docs/getting-started/integrate/node) to provide a more robust API implementation. However, the approach we took here makes sense for our use case. We have a simple API surface, it lives in a single file, we never call `fetch` directly and we don't need a lot of bells and whistles (like responding to different routes or query parameters). So for that reason this approach and the [spyOn](https://jestjs.io/docs/jest-object#jestspyonobject-methodname) approach used in some of the later lessons actually works really well.

If you're using [Apollo](https://www.apollographql.com/) or [ReactQuery](https://react-query.tanstack.com/) or [SWR](https://swr.vercel.app/) to handle your data, then you almost certainly should use [Mock Service Worker](https://mswjs.io/docs/getting-started/integrate/node) instead of the jest.mock approach.

Mocking out our API Helper with jest.mock

Code coverage is an important part of any test setup. One of the jest framework's innovations is built-in test coverage support. In this lesson I demonstrate using the [collectCoverageFrom](https://jestjs.io/docs/configuration#collectcoveragefrom-array) configuration option to improve jest's coverage support for TypeScript files and then demonstrate using `npx jest --coverage` to run code coverage as well as `npm test -- --coverage`, which does the same thing.

At the end I briefly mention the [collectCoverage](https://jestjs.io/docs/configuration#collectcoverage-boolean) flag which seems like you'd want to always just have on, but in practice is annoying. That's because coverage takes several extra to process and I rarely need my code coverage run, so it just makes the testing feedback loop a lot slower. For a build-only config it might make sense to leave on.

----

There's a [pretty good question on stackoverflow](https://stackoverflow.com/questions/43046885/what-does-do-when-running-an-npm-command) that covers using `--` with `npm test` that you might want to check out.

Here's an explanation of [how npx differs from npm](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b).


Configuring Code Coverage for TypeScript Files in Jest

Jest has a [watch mode](https://jestjs.io/docs/cli) that can really speed up test development. It will automatically run your tests as you save your test files. And it has a built-in pattern option to allow you to only focus on tests for a particular file. This approach works well in combination with [test.todo](https://jestjs.io/blog/2019/01/25/jest-24-refreshing-polished-typescript-friendly#testtodo) where you can stub out a number of tests and then code on them until they all pass.

Most of what is being done in these tests we've already seen before and it's important to note that I'm doing only the most basic of testing here. For each of these actions it wouldn't be uncommon in production to have 3-6 tests instead of just one.

It's important to note that `it` and `test` are aliases of one another so `it.todo` and `test.todo` both work seamlessly and are just a matter of preference. *Usually* when I'm doing unit testing I'll stick with `describe` and `it`, which commonly go together and I use `test` without `describe` when I'm testing react components with [React Testing Library](https://testing-library.com/docs/react-testing-library/intro).

Using Jest in Watch Mode with test.todo to Test a Redux Reducer

The app is built on top of [vite](https://vitejs.dev/) instead of the more popular [create react app](https://reactjs.org/docs/create-a-new-react-app.html). The benefit of vite is that it installs and builds extremely quickly. One of the downsides of vite is that it doesn't come with any out-of-the-box testing support. It also has its own [esbuild-based compiler](https://vitejs.dev/guide/features.html#typescript), which is not currently compatible with jest, so we have to configure JSX & TypeScript support for jest even though `vite` handles that already for our app.

This lesson requires installing a handful of modules:
```
npm install -D jest
npm install -D @testing-library/react @testing-library/jest-dom @testing-library/user-event
npm install -D @babel/preset-react @babel/preset-typescript @babel/preset-env
npm install -D identity-obj-proxy
```

Each of them serves an important purpose:

- [jest](https://jestjs.io/) _runs our tests_
- [@testing-library/react](https://testing-library.com/docs/react-testing-library/intro) adds the ability to render react components inside of our test environment
- [@testing-library/jest-dom](https://github.com/testing-library/jest-dom) _allows us to assert that components are in the DOM and contains certain text and classes_
- [@testing-library/user-event](https://testing-library.com/docs/ecosystem-user-event) _allows us to interact with rendered components programmatically_
- [@babel/preset-react](https://babeljs.io/docs/en/babel-preset-react), [@babel/preset-typescript](https://babeljs.io/docs/en/babel-preset-typescript), and [@babel/preset-env](https://babeljs.io/docs/en/babel-preset-env) allow us to use ES6 Modules, JSX, and TypeScript in our tests
- [identity-obj-proxy](https://github.com/keyz/identity-obj-proxy#identity-obj-proxy---) is helpful when rendering CSS modules so that we can see the original class names instead of obfuscated ones

We also have to add numerous config files such as `babel.config.js` and `jest-setup.ts` which are required to enable all of this functionality.

We put our `jest` config in our `package.json` file which works well, but you can also put it in a file named `jest.config.ts` or `jest.config.js`. See the [Jest Configuration Documentation](https://jestjs.io/docs/configuration) for more details about configuring jest.



Adding Jest with TypeScript Support to a Vite Application

In this lesson we go after the elusive goal of 100% test coverage by testing a few additional cases: error responses, empty error messages and the pending state that should exist between checkout being clicked and the API returning data.

The first two require special handling in our mock API:

```typescript
if (items.evilItem > 0) throw new Error();
if (items.badItem > 0) return { success: false };
```

In some ways these are arbitrary examples that may not exist in your other applications, but I wanted to demonstrate the fact that there are a lot of different ways an API might decide to communicate errors.

In general with AJAX calls a non-200 status response often gets thrown as an error and treated as an error case, but some APIs (such as graphql) include errors as part of a normal `200` response and need special handling. These lessons are meant to demonstrate what that might look like in your mocks.

Now it's useful to reiterate here that our simple API interface makes writing these mocks very easy, but in many cases something like [Mock Service Worker](https://mswjs.io/docs/getting-started/integrate/node) is a more appropriate way to mock out an API.

For our "pending" test, it's interesting what we lose when we stop focusing on actions fired (like in our previous 2 lessons) and instead focus purely on the resulting state. It makes looking at the intermediary state a bit more difficult. Here we work around that by calling `store.dispatch(thunk)` and saving the results of that to an `action` variable, which we `await` after doing an initial assertion. That `await` triggers our mock API to respond, so we can use the space between `dispatch` and `await` to peak into the pending state.

Additional Redux Thunk Unit Tests for Increased Code Coverage

Hardcoding your script to search for only one type of file (like `.md`) is a major limitation. This lesson shows you how to make your script smarter by teaching it to infer the desired file type directly from the user's natural language prompt.

You'll implement a two-stage AI process. The first stage analyzes the user's request to determine the file extension they're interested in (e.g., `md`, `txt`). The second stage then uses that file type to dynamically search the file system, find the relevant files, and execute the command.

**Workflow demonstrated in this lesson:**

* Add a preliminary `generateObject` call to extract a `fileType` from the user's initial prompt.
* Define a list of supported `fileTypes` (e.g., `['md', 'txt']`) and use a detailed prompt to guide the AI, instructing it to choose from the list or use a default.
* Dynamically construct the `globby` pattern using the inferred `fileType` (e.g., `*.$[fileType]`).
* Implement error handling to inform the user if they request an unsupported file type or if no files of the specified type are found.
* Demonstrate how the script defaults to searching for Markdown files but can correctly search for other types when specified (e.g., "summarize my profile from my pdf").

This technique adds a significant layer of intelligence to your script, allowing it to adapt its behavior based on the user's intent and making it a far more flexible and intuitive command-line tool.

John Lindquist

Dynamically Inferring File Types from User Prompts in Local AI Scripts

Hardcoding command logic and prompts directly into your script makes it rigid and difficult to extend. This lesson demonstrates a more flexible and powerful pattern: defining your script's commands as individual Markdown files in a dedicated directory.

This approach allows you to easily add, remove, or modify commands without touching the core script logic. You'll learn how to dynamically load these command files, present them as options to the AI, and inject the corresponding instructions into your prompt, creating a truly modular and extensible tool.

**Workflow demonstrated in this lesson:**

* Create a `commands` directory to house your command definitions (e.g., `summarize.md`, `translate.md`).
* In each file, write the specific prompt or instructions for that command.
* Use `globby` to discover all available command files at runtime.
* Create a `commandMap` that maps the filename (e.g., "summarize") to its file content.
* Update the Zod schema to use an `enum` of the dynamically discovered command names.
* Dynamically construct the final text generation prompt by injecting the instructions from the user-selected command file.
* Add a `profile.md` file to demonstrate how the script can act on user-created content with the new file-based commands.

By the end of this lesson, your script will be architected for easy expansion, allowing you to build a robust library of custom commands simply by adding new text files.

Creating Dynamic, File-Based Commands for Local AI Scripts

AI models won't always give you the answer you expect; sometimes they'll return invalid data or "hallucinate" a response that doesn't fit your schema. This lesson teaches you how to make your local AI script more robust by implementing essential error handling for user commands.

You'll learn how to validate the AI's output against a predefined list of valid commands and gracefully catch errors when the model generates an unexpected response, ensuring your script fails predictably and provides helpful feedback to the user.

**Workflow demonstrated in this lesson:**

* Define a list of `validCommands` (e.g., `summarize`, `translate`, `review`) to constrain the AI's choices.
* Wrap the `generateObject` call in a `try...catch` block to handle cases where the AI's output doesn't match the Zod schema.
* Implement a type guard function (`isValidCommand`) to check if the command returned by the AI is in your list of valid commands.
* Provide clear error messages to the user, indicating what went wrong and what the valid commands are.
* Test the script with invalid commands (like "taco" or "delete") to confirm that the error handling works as expected.

By adding these checks, you make your script significantly more reliable and user-friendly, preventing it from crashing on bad input and guiding the user toward correct usage.

Handling Invalid Commands and AI Errors in Local Scripts

Once your script can understand a user's command and identify a target file, the next step is to perform an action. This lesson shows you how to use the Vercel AI SDK's `generateText` function to process a file's content and produce a relevant, AI-generated response.

You'll learn how to read the content from the file path you've already identified, combine it with the inferred command into a new, more detailed prompt, and then pass it back to your local AI model to generate a final text output, such as a summary or a review.

**Workflow demonstrated in this lesson:**

* Import the `generateText` function from the `ai` SDK.
* Read the file content from the `filePath` returned by `generateObject`.
* Construct a new, structured prompt that includes the original command (e.g., "summarize") and the full content of the file.
* Pass this new prompt to the `generateText` function.
* Log the resulting AI-generated text to the console.
* Run the script with commands like "Summarize our TypeScript config" or "Review my package file" to see the full, context-aware output.

This lesson completes the core cycle of your AI script: understanding a command, reading the relevant context, and generating a useful, text-based result, all on your local machine.

Generating Text with a Local AI Model Based on File Content

A command is useless without knowing what to act upon. This lesson elevates your local AI script by giving it context from your project's file system. You'll learn how to find all relevant files and empower the AI to intelligently select the correct one based on your prompt.

The core technique involves using the `globby` package to scan for files and then feeding that list into a Zod `enum`. This constrains the AI's choices to a valid set of files, allowing it to accurately determine which file you're referring to in a natural language command.

**Workflow demonstrated in this lesson:**

* Install and import the `globby` library to find files based on a pattern (e.g., all `.json` files).
* Add a `filePath` field to your Zod schema.
* Define the `filePath` as `z.enum(files)`, where `files` is the array of file paths returned by `globby`.
* Pass a natural language prompt like "Summarize our typescript config" to the script.
* Observe how the AI correctly identifies `tsconfig.json` from the list of available JSON files and returns it as structured data.

This lesson is a crucial step toward building powerful, context-aware tools that can intelligently interact with your project's files based on simple, human-readable commands.

Providing File System Context to Local AI Scripts with Globby and Zod Enums

Hardcoded prompts are great for testing, but a truly useful script needs to respond to dynamic user input. This lesson shows you how to make your local AI script interactive by capturing command-line arguments.

You'll learn how to use Node.js's built-in `parseArgs` utility to take a user's natural language command directly from the terminal and pass it to your local language model for processing.

**Workflow demonstrated in this lesson:**

* Import the `parseArgs` function from the `node:util` module.
* Configure `parseArgs` to accept positional arguments from the command line.
* Replace the static, hardcoded prompt with the dynamic input provided by the user.
* Run the script with different sentences (e.g., `"Download a file"` or `"I want to download a file"`) to demonstrate that the AI can correctly infer the core command regardless of the phrasing.

By the end of this short lesson, your script will be able to accept and process commands directly from the user, making it a flexible and reusable command-line tool.

Processing Dynamic User Input in Local AI Scripts

While command-line chats with local AI models are useful, the real power comes from scripting. This lesson walks you through the initial setup for creating powerful, local AI-driven scripts by combining Ollama, the Vercel AI SDK, and Zod.

You'll learn how to take a natural language command, like "Concatenate all of the markdown files in my Downloads folder into a single file," and use the `generateObject` function to intelligently extract structured, actionable data from it.

**Workflow demonstrated in this lesson:**

* Install and set up the `ollama-ai-provider`, `ai`, and `zod` packages.
* Create a local AI model instance using Ollama and the Gemma 3 model.
* Define a Zod schema to specify the exact data structure you want to extract (e.g., `{ command: string }`).
* Use `generateObject` to pass a natural language prompt to the local model and receive a structured JSON object that matches your schema.
* Run the script using `bun` to see the local model successfully infer the "concatenate" command from a full sentence.

This foundational lesson unlocks the ability to build sophisticated, automated workflows by translating human language into machine-readable commands, all running entirely on your local machine.

Scripting Local Language Models with Ollama and the Vercel AI SDK

### **Build Powerful, Local AI-Driven Command-Line Scripts**

Go beyond simple AI chats and unlock the true potential of local language models by learning to script them. This course will guide you step-by-step through the process of building a flexible and intelligent command-line tool that can understand natural language, interact with your file system, and automate complex tasks—all running entirely on your local machine.

Starting with a blank TypeScript file, you'll learn how to combine the power of **Ollama**, the **Vercel AI SDK**, and **Zod** to create a script that's not just functional, but smart. We'll begin by teaching the AI to parse a simple command from a sentence. From there, we'll progressively add layers of sophistication: processing dynamic user input, making the script aware of your project's files, and generating meaningful text-based output.

You'll also learn critical patterns for building robust and extensible tools. We'll cover how to handle invalid commands and unexpected AI responses gracefully. Then, you'll refactor the script to use a modular, file-based system for its commands, allowing you to easily add new functionality without touching the core logic. Finally, we'll add a layer of intelligence that allows your script to infer exactly what you mean, right down to the type of file you want it to process.

By the end of this course, you will have built a powerful, personalized AI assistant and gained the foundational skills to create sophisticated local automations for any task you can imagine.

**What You'll Learn:**

* How to script local language models using Ollama and the Vercel AI SDK.
* To parse and process dynamic user input from the command line.
* To use Zod schemas, including `enums`, to validate and structure AI model output.
* Techniques for providing file-system context to your scripts with `globby`.
* How to generate context-aware text based on file content.
* Robust error handling for invalid user commands and unexpected AI responses.
* To build a modular and extensible tool by defining commands in separate files.
* To intelligently infer user intent, such as dynamically determining file types from a prompt.

Build a local AI-powered command-line assistant from scratch. Learn to use Ollama, Vercel AI SDK & Zod to parse input, automate tasks, and run scripts offline.

This lesson demonstrates how to give Cursor direct access to your terminal output using the [Nx MCP extension](https://nx.dev/getting-started/ai-integration?utm_source=youtube&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI), enabling automatic error detection and fixing in monorepo projects.

**Workflow demonstrated in this lesson:**

- Encounter a runtime error when serving a Vite application in an Nx monorepo
- Install and configure the Nx Console extension with MCP integration
- Ask Cursor to check your terminal for errors and fix the underlying issues
- Watch as the AI accesses running task details and terminal output through Nx MCP tools
- Observe how it analyzes workspace relationships to identify incorrect imports and missing dependencies

**Key benefits:**

- Seamless Error Handling: AI gains direct access to terminal output and running task information
- Automatic Diagnosis: Accurately identify the root cause of errors without manual copying
- Context-Aware Fixes: Leverage workspace knowledge to implement proper solutions
- Reduced Context Switching: Eliminate the need to manually relay information between terminal and AI



Juri Strumpflohner

Enable Cursor to directly access the terminal to read the output and fix issues

See how Nx MCP gives AI coding assistants direct access to terminal output and running tasks, enabling automatic error detection and fixing.

This lesson demonstrates how to solve the predictability problem when using AI to generate code in monorepos by combining Cursor with Nx generators.

**Workflow demonstrated in this lesson:**

- Explore how Nx generators provide predictable scaffolding for new libraries
- Set up [Nx Console with MCP](https://nx.dev/features/enhance-AI?utm_source=egghead&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI) integration to expose generator capabilities to Cursor
- Use the AI assistant to brainstorm a new feature with the help of the Nx MCP tools
- Have Cursor leverage the Nx MCP tools to trigger the appropriate Nx generator for creating a React-based feature library
- Observe how the AI assistant takes the generated library and further integrates it into the codebase

**Key benefits:**

- **Predictable Code Structure**: Ensure generated libraries follow your project's and organization's conventions
- **Consistent Setup**: Maintain uniform configuration across TypeScript projects and package.json files
- **Guided Implementation**: Combine AI instructions with structured, predictable code generation

Enable Cursor to generate predictable project setups

Learn how to combine Cursor AI with Nx generators for predictable library creation in monorepos, ensuring consistent structure across your codebase.

Search

Search Results