Code Loading Lesson

MDX Powered Lesson

Codesandbox Embed Lesson

Replit Embed Lesson

Getting Oriented

Initial setup for pnpm and Node version management

How pnpm organizes node_modules

Configuring pnpm peer dependencies and hoisting

Setting up a pnpm workspace monorepo

Production vs development dependencies

Dependency version ranges and protocols

Patching dependencies with pnpm

Introduction

Adding a formatter with Prettier

Sharing TypeScript configuration

Shared ESLint configuration for ESLint 8 and 9

VSCode ESLint extension hoisting workaround

Shared testing configuration with Jest and Vitest

Shared config

Automated git hooks with Lefthook

Pre-commit formatting with pretty-quick

Benchmarking and speeding up pre-commit hooks

Finding unused dependencies with Knip

Should Knip run in pre-commit?

Enforcing monorepo dependency consistency with Sherif

Per-workspace pre-commit checks with Lefthook

Tools and techniques for managing and automating tasks within a monorepo

Monorepo management and automation tools

CommonJS vs ESM in Node

Node.js package.json exports

How TypeScript Picks an exports Condition

Sharing UI code by exporting TypeScript

When exporting TypeScript breaks (and how to fix it)

Adding Preconstruct to Our Monorepo

Preconstruct for logger and automatic dev symlinks

Explore Node.js fundamentals and TypeScript build tools essential for effective monorepo management.

Understanding Node fundamentals and TypeScript build tools in a Monorepo

Module 05 — CI/CD

Adding a basic GitHub Actions CI workflow

CI concurrency and push triggers

Extracting a composite GitHub Action for pnpm and Node

Running Sherif in CI without pnpm install

Splitting CI into multiple fast checks

Pinning GitHub Actions by full SHA

Adding workflow_dispatch

Building a single workspace with Docker

Explore strategies and tools for implementing continuous integration and deployment in monorepo environments.

Continuous Integration and Deployment in Monorepos

Initial Turborepo setup

Build and start with Turborepo

Turbo transit tasks

Workspace-specific turbo config

Environment variables in Turborepo

Custom inputs and global dependencies

Workaround for turbo cache symlink bug

Learn how to use Turborepo for efficient monorepo management, including caching, parallel builds, and task orchestration.

Turborepo

( the primaryDescriptionMarkdown is long - several lines, include images, as long as you want )

In this course we <headline of what we do>. <why this technology is good> but <here's how learning it is problem>. 

In <the length of these lessons> we cover <three salient points about what we cover. Your BEST points>. Its <however long it is> and comes with <these bonus features, and reasons to buy. code, etc.>

It's taught by <author name> who <credibility, reason you should listen to them>. <social proof, if you have it yet>

<then you can list other supporting stuff you want to add, anything you want here>

-------
Example:
-------

We created a free course to create your first GraphQL server (from scratch) using Node and TypeScript. TypeScript and GraphQL are a powerful combo, but there's a lot of confusing edges if you're getting it setup the first time.

In this course we cover the basics of getting TypeScript setup with Node, how GraphQL works, and how to set up a GraphQL server using Apollo server. It's two hours long, it comes with complete code examples, and we walk through the code step-by-step.

It's taught by my friend, Shopify-engineer Hassan Djirdeh and he's integrated what he's learned using GraphQL in production as an engineer at Shopify. We've already had over 1,300 students enroll and it's been getting great reviews so far.

// ... and so on

In this course we <headline of what we do>. <why this technology is good> but <here's how learning it is problem>. 

( the summary is short - one or two lines )

Bundling and Automation in Monorepos

In this lesson, we’ll get practical about 

When we add a dependency without choosing a specific range, package managers typically save it with a caret prefix.

For example, after adding TypeScript, we’ll see something like this:

{
  "dependencies": {
    "typescript": "^5.7.2"
  }
}

This is usually a good default: minor and patch upgrades are easy, while major upgrades require an intentional change.

Here’s a practical cheat sheet for the version specifiers we’ll see most often:

 versions are treated more cautiously. A caret range like 

 behaves more like “stay within this minor”, because breaking changes are expected more frequently.

, which are named pointers to versions. TypeScript, for example, publishes tags like 

That means these are valid version specifiers:

{
  "dependencies": {
    "typescript": "next"
  }
}

Using tags can be useful for evaluating upcoming releases (for example, experimenting with the 

 channel), but it also makes installs less reproducible unless you control upgrades carefully.

---
title: Dependency version ranges and protocols
privateVideoUrl: https://stream.mux.com/NRuZx5sjERhQf2iPczQHdh2vk2yJfhDTJg51Wn8vAAI.m3u8
isPublicLesson: false
code:
---

# Dependency version ranges and protocols

In this lesson, we’ll get practical about **what a version specifier really means** in `package.json`, and what extra power we gain from **dependency protocols**.

Version ranges answer one question:

-   When we upgrade dependencies, what is the _maximum_ version this dependency is allowed to move to?

Protocols answer a different question:

-   Where should this dependency come from (npm, our workspace, a file path, GitHub, etc.)?

## The default: caret (`^`)

When we add a dependency without choosing a specific range, package managers typically save it with a caret prefix.

For example, after adding TypeScript, we’ll see something like this:

**package.json (snippet)**

```json
{
  "dependencies": {
    "typescript": "^5.7.2"
  }
}
```

The important part is the caret: `^5.7.2`.

-   `5.7.2` is the minimum allowed version.
-   The caret means we can upgrade within the same major version (so `5.x.x` is allowed, but `6.0.0` is not).

This is usually a good default: minor and patch upgrades are easy, while major upgrades require an intentional change.

## Common version range patterns

Here’s a practical cheat sheet for the version specifiers we’ll see most often:

| Example              | Effective range      | Description                                                       |
| -------------------- | -------------------- | ----------------------------------------------------------------- |
| `^1.2.3`             | `>=1.2.3 <2.0.0`     | Allows minor and patch updates, locks major.                      |
| `1.2.3`              | `=1.2.3`             | Exact version only.                                               |
| `~1.2.3`             | `>=1.2.3 <1.3.0`     | Allows patch updates, locks minor.                                |
| `^0.2.3`             | `>=0.2.3 <0.3.0`     | For `<1.0.0`: caret stays within the same minor.                  |
| `*`                  | `>=0.0.0`            | Matches any version.                                              |
| `1.x`                | `>=1.0.0 <2.0.0`     | Matches any minor/patch within major `1`.                         |
| `1.2.x`              | `>=1.2.0 <1.3.0`     | Matches any patch within minor `1.2`.                             |
| `>1.2.3`             | `>1.2.3`             | Any version greater than `1.2.3`.                                 |
| `<1.2.3`             | `<1.2.3`             | Any version less than `1.2.3`.                                    |
| `>=1.2.3`            | `>=1.2.3`            | Any version greater than or equal.                                |
| `<=1.2.3`            | `<=1.2.3`            | Any version less than or equal.                                   |
| `1.2.3 - 2.3.4`      | `>=1.2.3 <=2.3.4`    | Inclusive range.                                                  |
| `1.2.3 \|\| 2.3.4`   | `=1.2.3 \|\| =2.3.4` | Either of the two versions.                                       |
| `^1 \|\| ^2 \|\| ^3` | `>=1.0.0 <4.0.0`     | A common multi-major range.                                       |
| `1.2.3-beta.0`       | `=1.2.3-beta.0`      | A specific pre-release version.                                   |
| `latest`             | N/A                  | Always resolves to the latest published version (similar to `*`). |
| `next`               | N/A                  | Resolves to a dist-tag named `next` if it exists.                 |