Learn Mac, Ramda and Turborepo

Turborepo is a fast build system for JavaScript and TypeScript.

turborepo

Turborepo is a task runner that helps speed up and manage your Monorepos. It's not a dependency management tool. It knows nothing about your dependencies. 

It speeds up Monorepos by using local and remote caching as well as incremental builds. It helps to manage your repo with very handy and easy-to-use scripts. 

Here is the [npm-workspaces repo](https://github.com/alejandronanez/npm-workspaces)

So let's hop in and learn about Turborepo!

Note: This course is a continuation of the course [Introduction to Monorepos with NPM Workspaces](https://egghead.io/courses/introduction-to-monorepos-with-npm-workspaces-c03f500b) where we initially build out the Monorepo that is used in this course. It is highly suggested to watch that course first before jumping into this one. 

What is Turborepo?

At the root of our project, we'll run `npm install turbo --save-dev` to install Turborepo.

We'll also look at how to configure Turborepo in the `turbo.json` file. We'll look into the [$schema](https://turborepo.org/schema.json) and how it affects our configuration. 

Install Turborepo in an Existing Monorepo

With our npm scripts, if utils can't build, then the dashboard and blog can't build or run their tests. Turborepo Pipelines changes that. Using the pipeline, we can set up caching, what our scripts depend on, and where we want our logs to be output. 

Also since we now have Turborepo installed and configured our pipelines, we can remove concurrently from our scripts and dependencies. 

Migrate NPM Scripts to Turborepo Pipelines

We are going to be going through Turborepo speeds up your builds and testing with caching. When a command is first run in Turborepo, it gets cached. This way if something has changed in one of your repos in your Monorepo, it will detect that change. For the repos that haven't changed, it will pull their info from the cache inside of `node_modules` instead of fully re-running that command. For the repo that has changed, it will run that command solely on that repo. 

Understand Turborepo Local Cache

It's fairly straight forward to create repo specific pipelines with Turborepo. The script goes like this: `{monorepo-name}/{repository}#{script-name}`. For example, if we wanted to run the typecheck command in just the dashboard repo, it would look like this: `@monorepo/dashboard#typecheck`. Lastly, we will make sure that it `dependsOn` the `utils#typecheck` pipeline. 

Create Repository Specific Turborepo Pipelines

A dependency graph is exactly what it sounds like! A visual graph created by Turborepo to show you your dependencies and what dependencies the projects rely on. For our Monorepo, we'll run `npx turbo run build --graph` in the root of our project and that will build the dependency graph for all of our projects.

We can also do one with a graphic but that requires the [Graphviz](https://graphviz.org/download/) library. We can edit our command to have some arguments: `npx turbo run build --graph=graph.pdf` and it will create a graphic in a .pdf file. 

Generate a Dependency Graph for Monorepos Using Turborepo

You can set up all of your specific pipelines in the turbo.json file, or you can filter through your pipelines in the terminal. If we wanted to run the `typecheck` command in just the `utils` package, our command would look like this: `npx turbo run typecheck --filter=@monorepo/utils`. You can remove `@monorepo` as long as the `utils` package is unique. 

Turborepo also gives you the option to filter your commands based on what files have changed on your branch using `--filter="[HEAD^1]". 

Now that we know a bit more about Turborepo, we can edit all of the scripts that we build in the previous course to use `turbo` instead of `npm`. 

Filter Pipeline Tasks Using Turborepo

By default, Turborepo will stop its execution if it runs into an error. We may not want that if we want Turborepo to continue in the projects that don't have an error. We can do this by adding the `--continue` flag to the end of our command. 

Prevent Turborepo Exiting Early on Failing Tasks

Another really good tool that Turborepo offers is the `--dry` flag. The `dry` flag will display details about the affected workspaces and tasks that would be run. It will help you to know what Turborepo is doing under the hood. 

Preview Turborepo Tasks at the Pipeline Level

The logs produced by Turborepo can get really really long. Turborepo give us a flag, `--output-logs` and if we add on the argument `new-only`, it shortens the logs to just the new information for the repositories that have changed. 

Shorten Turborepo Logs using --output-logs

Remote caching is key when coworking on a project. Using Turborepo, you can upload your cache to the cloud and use it everywhere else. For example, if your coworker switches to your branch and runs the build, they can have your most recent cache saving them time. 

We will start off by logging into Vercel and Turborepo then linking our Turborepo account to our Vercel account. Once that is done, we run `npx turbo link` to connect to our remote cache. Then in our Vercel dashboard, we will need to do some configuring to finish it up. 

Enable Remote Caching in Vercel

Now that we have Turborepo installed, configured, and we have some knowledge about it, let's deploy our two client-side applications, dashboard and blog, to Vercel. We'll link our Github to Vercel and point it towards our Monorepo. We'll then run through all of the configurations and commands needed to get our apps deployed. 

Deploy the Client-Side Apps in a Turborepo Monorepo to Vercel

Github Actions helps to automate the building, testing, and deploying of your applications. We'll configure our actions in the `ci.yml` file in a new directory called `.github/workflows`. When that file is configured, we can update our scripts in our package.json to run off of those. We will also need to make/set up our `TURBO_TOKEN` and our `TURBO_TEAM` which we will create on Vercel and Github. 

Enable Github Actions with Turbporepo Remote Caching

Now you might have a project that currently isn't in your Monorepo that you want to add to it. We can copy that project over into our `apps` folder and then update the `package.json` to update the name to make it consistent across our apps. We'll update the dev port to make sure it's not going to run on the same port as one of our other applications. Lastly, we'll update the build pipeline to include our new application. 

Migrate a VueJS Application to an Existing Turborepo Monorepo

Switching project contexts causes needless friction and opportunities for distraction as we try to pull up related tabs and applications. I learned a trick from [David Sparks](https://www.macsparky.com/) on how to use the Mac automation software [Keyboard Maestro](https://www.keyboardmaestro.com/main/) to create palettes of shortcuts grouped by context. This has been an awesome boost to my productivity!

Seamlessly Switch Project Contexts with Keyboard Maestro

PostgreSQL is a powerful, open source object-relational database system.

postgres

YugabyteDB is an open source, high-performance distributed SQL database for powering global, internet-scale applications.YugabyteDB is also a cloud-native database, so it can be deployed across both public and private clouds, including  Kubernetes environments. In regards to serving as a backend for microservices, YugabyteDB brings together three must-haves: a PostgreSQL-compatible SQL API, low-latency read performance, and globally distributed write scalability. YugabyteDB with its global data distribution brings data close to users for multi-region and multi-cloud deployments. 

In this lesson we will see how we can create YugabyteDB cluster locally on our Mac for dev environment and prototyping 

Set up YugabyteDB Distributed SQL Cluster Locally on MacOS

In this video, we'll learn how to modify the default screenshot keyboard shortcut on macOS so that it copies our screenshot to our clipboard. This comes in handy if you share screenshots often.

Change Default Screenshot Key to Copy to Clipboard

Joe Previte is an active egghead instructor and blogger. This is a collection of screencast versions of selected blog posts. You can find his blog here: [joeprevite.com](https://joeprevite.com/)

Joe's Blog Posts as Screencasts

Just about every tool in our accessibility auditing toolkit can help us identify any issues with sufficient color contrast ratio on a web page.  The react-axe library and axe browser extension both report findings on all elements with insufficient contrast ratios.  The tota11y browser extension will annotate any elements with their contrast ratios and color those that are insufficient in red.  

Additionally, we need to use our experience tools to see what some of our users out there may we seeing.  We need to test with high contrast browser extensions as well as the display settings in Windows and Mac.  If our users with visual impairments are using these tools we need to see what our application looks like using them because we may find that under a certain mode some things may suddenly be harder to read or virtually invisible.

## Resources
* https://www.scottohara.me/blog/2019/02/12/high-contrast-aria-and-images.html

Test for Insufficient Color Contrast Accessibility Issues

We should not use color alone as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.  Users may not be able to see/understand the differences in color and require additional indicators.

Along with color, use additional indicators such as:
* typography
* shapes
* grids
* spaces
* and/or allocate more weight to important elements

## References:
* http://www.particletree.com/features/interfaces-and-color-blindness/
* https://www.smashingmagazine.com/2014/10/color-contrast-tips-and-tools-for-accessibility/

Use More than Color Alone to Convey Information in a Web Page

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. 

aria

It's very important to experience our web applications using the tools and techniques that our users are using.  Many of our users out there may have vision impairments and may use tools or adjust settings to help them see better. Learn how to change the accessibility display preferences on Mac to test your application for issues that may arise due to a lack of contrast between foreground and background colors in your web application which can be exacerbated when users have to adjust these display preferences.

## Resources
* [MacOS Display Preferences User Guide] (https://support.apple.com/guide/mac-help/change-accessibility-display-preferences-unac089/mac)

Change Display Preferences on Mac to Find Color Contrast Accessibility Issues

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