Monorepo English: pnpm Workspaces and Turborepo Vocabulary
Master the English vocabulary of monorepo tooling — workspaces, hoisting, build pipelines, and topological order — used daily with pnpm and Turborepo.
Introduction
Modern front-end and full-stack teams increasingly organise their code in a monorepo — a single repository that contains multiple packages or applications. Tools like pnpm Workspaces and Turborepo have their own technical vocabulary that can be confusing even for experienced developers. For non-native English speakers, the challenge is doubled: you must understand both the concept and the English phrase used to describe it. This post teaches you the most important terms so you can follow documentation, code reviews, and team discussions with confidence.
What Is a Workspace?
In pnpm, a workspace is a collection of packages managed together inside one repository. You define workspaces in a file called pnpm-workspace.yaml. When a colleague says “add it as a workspace dependency”, they mean the package should be linked locally rather than downloaded from a registry.
The workspace protocol is the special syntax workspace:* that you write in package.json to reference another local package. For example: “Use the workspace protocol so changes in the shared library are immediately visible to the app package.” This avoids publishing a package to npm just to test it.
Dependency hoisting is the practice of moving shared packages up to the root node_modules folder instead of installing separate copies inside each package. You might hear: “pnpm uses a stricter hoisting strategy than npm to prevent phantom dependencies.”
A phantom dependency is a package that your code uses but that is not listed in your own package.json. It works only because another package happens to install it. This is considered a bug. Example sentence: “The build broke in CI because we had a phantom dependency on lodash — it was hoisted from a sibling package in development.”
Turborepo Concepts
Turborepo is a high-performance build system for monorepos. Its central idea is that if nothing has changed, you should not rebuild. This is called incremental build.
A cache hit occurs when Turborepo finds a stored result for a task and reuses it instead of running the task again. The opposite is a cache miss. In conversation: “The CI run was fast because almost every task got a cache hit — only the package we modified needed to rebuild.”
Cache invalidation is the process of deciding when a cached result is no longer valid and must be discarded. It is one of the famously hard problems in computer science. You will hear: “Changing a shared config file causes cache invalidation for every package that depends on it.”
Build Pipelines and Ordering
A build pipeline in Turborepo is the configuration that defines which tasks depend on which other tasks. You write it in turbo.json. Example: “Our build pipeline runs lint and test in parallel, then waits for both before starting the deploy task.”
Topological order (also called topological sort) means executing tasks in the order that respects dependencies — a package must be built before any package that depends on it can be built. “Turborepo automatically determines the topological order of builds across all workspace packages.”
A package graph is the map of all packages and their dependency relationships inside the monorepo. When you run turbo build, it reads this graph to know which packages to build and in what order. “Adding a new dependency between two packages changes the shape of the package graph and may slow down parallel builds.”
Key Vocabulary
| Term | Definition |
|---|---|
| workspace | A set of packages managed together in one repository |
| workspace protocol | The workspace:* syntax that links local packages in package.json |
| dependency hoisting | Moving shared packages to the root node_modules to avoid duplication |
| phantom dependency | A package used in code but not declared in package.json |
| cache hit | When a build tool reuses a stored result instead of re-running a task |
| cache invalidation | Deciding that a cached result is outdated and must be discarded |
| topological sort | Ordering tasks so that dependencies always run before dependants |
| build pipeline | Configuration that defines task execution order and parallelism |
Practice Tips
-
Read
turbo.jsonout loud. When you see a pipeline definition, try to describe it in a sentence: “The build task depends on the build task of all dependencies running first.” Saying it aloud helps fix the vocabulary in memory. -
Explain hoisting to a teammate. Teaching is one of the best ways to learn language. Try to describe phantom dependencies and why pnpm’s strict hoisting prevents them.
-
Use the correct prepositions. We say “a cache hit on a task”, “a dependency on a package”, and “hoisting to the root”. Notice these small words — they are easy to miss but important for sounding fluent.
-
Follow the Turborepo and pnpm changelogs. Release notes are written in clear technical English and use these terms in real sentences. Reading one entry per week builds vocabulary naturally.
Conclusion
Monorepo tooling has a rich vocabulary that describes real engineering trade-offs — speed versus correctness, isolation versus convenience. Once you understand terms like workspace protocol, dependency hoisting, cache invalidation, and topological sort, you can participate fully in architectural discussions and code reviews. Practice using these phrases in context and you will quickly feel at home in any monorepo team conversation.