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

 cooperate to make TypeScript understand which 

 condition will be matched, and load the appropriate types.

"What would Node (or your bundler) try first?"


TypeScript asks the same question while loading the types for libraries you import.

https://www.typescriptlang.org/docs/handbook/modules/reference.html

You can insert additional conditions for TS to add to the resolve stack by using 

 may in some arcane situations more accurately mimic how a bundler would resolve a badly authored npm package.
In 99% of the cases you don't need this, and touching it will lead to pain.

https://www.typescriptlang.org/tsconfig/#customConditions

# How TypeScript Picks an `exports` Condition

> _Goal:_ Understand how `module` and `moduleResolution` compiler options in `tsconfig.json` cooperate to make TypeScript understand which `package.json#exports` condition will be matched, and load the appropriate types.

* * *

## Background refresher

1.  `module` decides _how each file is emitted_ (ES `import/export`, CJS `require`/`module.exports`, or "leave it untouched").
2.  `moduleResolution` decides _where to look_ for the symbol: classic Node rules, Node ≥ 16 dual‑graph rules, or the looser "bundler" rules.
3.  When TypeScript walks a package's `exports` object it **always adds** the conditions `"types"` and `"default"`.
    The remaining conditions depend on the information from (1) + (2):

    -   If the JS we are emitting is **ESM** ➡ the resolver adds the `"import"` condition (and, for Node‑style modes, `"node"`).
    -   If the JS we are emitting is **CJS** ➡ the resolver adds the `"require"` condition (plus `"node"` where applicable).
    -   Consult <https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution>

Put differently: _"What would Node (or your bundler) try first?"_
TypeScript asks the same question while loading the types for libraries you import.

* * *

## Popular option combinations

| #   | `module`                                                                                    | `moduleResolution`      | Target runtime / tool                  | Export conditions considered¹                                                                      |
| --- | ------------------------------------------------------------------------------------------- | ----------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------------- |
| 1   | `preserve`                                                                                  | `bundler` (implied)     | Vite, esbuild, Bun, tsx, Turbopack     | per‑statement: (`import` → [`types`, `import`]) (`require` → [`types`, `require`])                 |
|     | `preserve` keeps the original syntax; bundlers read `.ts` directly.                         |                         |                                        |                                                                                                    |
| 2   | `esnext`                                                                                    | `bundler`               | Browser bundles where code is ESM‑only | Always [`types`, `import`]                                                                         |
|     | Slightly simpler than #1 -- no mixed module syntax.                                         |                         |                                        |                                                                                                    |
| 3   | `nodenext`                                                                                  | `nodenext` (implied)    | Node ≥ 20, libs meant for Node         | per-statement: (`import` → [`types`, `node`, `import`]) (`require` → [`types`, `node`, `require`]) |
|     | Mirrors Node's real dual‑graph rules; understands package `type:"module"`, `.mts/.cts` etc. |                         |                                        |                                                                                                    |
| 4   | `commonjs`                                                                                  | `node10` (alias `node`) | Legacy Node ≤ 12 or Jest‑only libs     | Always [`types`, `require`]                                                                        |
|     | **No support** for `exports` -- if the package omits legacy `main` field, resolution fails. |                         |                                        |                                                                                                    |