Monorepo Tooling Vocabulary
Practice English vocabulary for monorepo tooling concepts: workspaces, lockfiles, build systems, and shared configuration.
0 / 32 completed
1 / 32
What does 'the workspace package is auto-linked' mean?
In monorepo workspace setups (npm/yarn/pnpm workspaces), packages within the repo are automatically linked so you can import them as if they were installed from npm.
2 / 32
A developer says 'pnpm's strict lockfile prevents phantom dependencies'. What is a phantom dependency?
Phantom dependencies occur when a package is accessible because it was hoisted to node_modules by a parent package, even though it is not declared in your own package.json. pnpm's strict mode prevents this.
3 / 32
What does 'the build system only rebuilds affected packages' mean?
Modern monorepo build tools like Turborepo and Nx use dependency graphs and caching to skip rebuilding packages that have not changed, drastically reducing build times.
4 / 32
What is meant by 'the shared ESLint config is in the root'?
Monorepos often place shared tooling configs (ESLint, Prettier, TypeScript base) in the root so all packages inherit the same rules, with packages able to extend or override as needed.
5 / 32
What does 'workspace protocol (workspace:*)' mean in a monorepo dependency declaration?
The 'workspace:*' protocol (used by pnpm and Yarn) tells the package manager to always resolve the dependency from the local workspace, ensuring you always use the local source during development.
6 / 32
David: 'I've flagged a PR with a new feature. The build is failing because it's trying to install lodash@4.17.21, but I didn't explicitly declare that dependency in this package!'. Sarah replies: 'That sounds like a problem with the monorepo tooling. Can you check if the workspace is correctly configured to resolve dependencies?' What does Sarah likely mean by 'the workspace is correctly configured' in this scenario?Sarah's statement refers to the core functionality of a monorepo tooling – automated dependency resolution. The workspace protocol allows packages to 'look up' dependencies in other parts of the repository based on declared ranges (e.g., `^4.17.21`). Incorrectly, David's response suggests manual pinning; this bypasses that automation and can lead to inconsistencies. The correct configuration ensures all dependent packages use the same, resolved version.
7 / 32
PR Description:
Subject: Add new User Authentication Service
This PR introduces a new service for user authentication. It utilizes the AuthService from the core monorepo and depends on lodash@4.17.21 for utility functions. The build process is failing with an error related to this dependency not being found. The team lead comments: 'Looks like we're missing a critical dependency declaration here.'
What does the team lead likely mean by 'we're missing a critical dependency declaration' in the context of the monorepo?The team lead is referring to how monorepos manage dependencies. When a package declares a dependency on another package within the monorepo, the tooling (like
pnpm or yarn workspaces) automatically resolves that dependency. Missing an explicit declaration means the resolver doesn't know about this dependency, leading to build failures; therefore, explicitly declaring it in the package.json is the correct action.8 / 32
Reviewer: 'The CI is failing because the new React component is trying to import utils.js from the `frontend` package, but that package doesn't have a public API! It's only meant for internal use within the frontend itself.' You are the developer working on the PR.
What does the reviewer likely mean by 'doesn't have a public API'?
The reviewer is highlighting a core principle of monorepos: code isolation and dependency management. Saying 'doesn't have a public API' correctly identifies that the
utils.js file was designed as an internal module *specifically* for use within the `frontend` package, preventing unintended dependencies and potential conflicts across the entire monorepo. Option A is close but focuses on hiding files rather than the intended purpose of a private API.9 / 32
During a code review, Alex says: "I've run `pnpm install` in this package, but the build is still failing and it's complaining about missing dependencies. It seems like the monorepo isn't resolving them correctly.". What does Alex likely mean when he refers to 'the monorepo not resolving them correctly'?
Alex is referring to a core concept of monorepos: dependency resolution. The monorepo tooling (like pnpm or yarn) manages the relationships between packages. When a package depends on another, the tooling must correctly identify and install all necessary dependencies, ensuring they are available across the entire repository. The incorrect option suggests a simple installation failure; this question focuses on the *tooling's* role in resolving those dependencies, rather than a user-level error.
10 / 32
David: 'I've flagged a PR with a new feature. The build is failing because it's trying to install lodash@4.17.21, but I didn't explicitly declare that dependency in this package!'. Sarah replies: 'That sounds like a problem with the monorepo tooling. Can you check if the workspace is correctly configured to resolve dependencies?' What does Sarah likely mean by 'the workspace is correctly configured' in this scenario?Sarah's statement refers to the core functionality of a monorepo tooling – automated dependency resolution. The workspace protocol allows packages to 'look up' dependencies in other parts of the repository based on declared ranges (e.g., `^4.17.21`). Incorrectly, David's response suggests manual pinning; this bypasses that automation and can lead to inconsistencies. The correct configuration ensures all dependent packages use the same, resolved version.
11 / 32
PR Description:
Subject: Add new User Authentication Service
This PR introduces a new service for user authentication. It utilizes the AuthService from the core monorepo and depends on lodash@4.17.21 for utility functions. The build process is failing with an error related to this dependency not being found. The team lead comments: 'Looks like we're missing a critical dependency declaration here.'
What does the team lead likely mean by 'we're missing a critical dependency declaration' in the context of the monorepo?The team lead is referring to how monorepos manage dependencies. When a package declares a dependency on another package within the monorepo, the tooling (like
pnpm or yarn workspaces) automatically resolves that dependency. Missing an explicit declaration means the resolver doesn't know about this dependency, leading to build failures; therefore, explicitly declaring it in the package.json is the correct action.12 / 32
Reviewer: 'The CI is failing because the new React component is trying to import utils.js from the `frontend` package, but that package doesn't have a public API! It's only meant for internal use within the frontend itself.' You are the developer working on the PR.
What does the reviewer likely mean by 'doesn't have a public API'?
The reviewer is highlighting a core principle of monorepos: code isolation and dependency management. Saying 'doesn't have a public API' correctly identifies that the
utils.js file was designed as an internal module *specifically* for use within the `frontend` package, preventing unintended dependencies and potential conflicts across the entire monorepo. Option A is close but focuses on hiding files rather than the intended purpose of a private API.13 / 32
During a code review, Alex says: "I've run `pnpm install` in this package, but the build is still failing and it's complaining about missing dependencies. It seems like the monorepo isn't resolving them correctly.". What does Alex likely mean when he refers to 'the monorepo not resolving them correctly'?
Alex is referring to a core concept of monorepos: dependency resolution. The monorepo tooling (like pnpm or yarn) manages the relationships between packages. When a package depends on another, the tooling must correctly identify and install all necessary dependencies, ensuring they are available across the entire repository. The incorrect option suggests a simple installation failure; this question focuses on the *tooling's* role in resolving those dependencies, rather than a user-level error.
14 / 32
David: 'I've flagged a PR with a new feature. The build is failing because it's trying to install lodash@4.17.21, but I didn't explicitly declare that dependency in this package!'. Sarah replies: 'That sounds like a problem with the monorepo tooling. Can you check if the workspace is correctly configured to resolve dependencies?' What does Sarah likely mean by 'the workspace is correctly configured' in this scenario?Sarah's statement refers to the core functionality of a monorepo tooling – automated dependency resolution. The workspace protocol allows packages to 'look up' dependencies in other parts of the repository based on declared ranges (e.g., `^4.17.21`). Incorrectly, David's response suggests manual pinning; this bypasses that automation and can lead to inconsistencies. The correct configuration ensures all dependent packages use the same, resolved version.
15 / 32
PR Description:
Subject: Add new User Authentication Service
This PR introduces a new service for user authentication. It utilizes the AuthService from the core monorepo and depends on lodash@4.17.21 for utility functions. The build process is failing with an error related to this dependency not being found. The team lead comments: 'Looks like we're missing a critical dependency declaration here.'
What does the team lead likely mean by 'we're missing a critical dependency declaration' in the context of the monorepo?The team lead is referring to how monorepos manage dependencies. When a package declares a dependency on another package within the monorepo, the tooling (like
pnpm or yarn workspaces) automatically resolves that dependency. Missing an explicit declaration means the resolver doesn't know about this dependency, leading to build failures; therefore, explicitly declaring it in the package.json is the correct action.16 / 32
Reviewer: 'The CI is failing because the new React component is trying to import utils.js from the `frontend` package, but that package doesn't have a public API! It's only meant for internal use within the frontend itself.' You are the developer working on the PR.
What does the reviewer likely mean by 'doesn't have a public API'?
The reviewer is highlighting a core principle of monorepos: code isolation and dependency management. Saying 'doesn't have a public API' correctly identifies that the
utils.js file was designed as an internal module *specifically* for use within the `frontend` package, preventing unintended dependencies and potential conflicts across the entire monorepo. Option A is close but focuses on hiding files rather than the intended purpose of a private API.17 / 32
During a code review, Alex says: "I've run `pnpm install` in this package, but the build is still failing and it's complaining about missing dependencies. It seems like the monorepo isn't resolving them correctly.". What does Alex likely mean when he refers to 'the monorepo not resolving them correctly'?
Alex is referring to a core concept of monorepos: dependency resolution. The monorepo tooling (like pnpm or yarn) manages the relationships between packages. When a package depends on another, the tooling must correctly identify and install all necessary dependencies, ensuring they are available across the entire repository. The incorrect option suggests a simple installation failure; this question focuses on the *tooling's* role in resolving those dependencies, rather than a user-level error.
18 / 32
David: 'I've flagged a PR with a new feature. The build is failing because it's trying to install lodash@4.17.21, but I didn't explicitly declare that dependency in this package!'. Sarah replies: 'That sounds like a problem with the monorepo tooling. Can you check if the workspace is correctly configured to resolve dependencies?' What does Sarah likely mean by 'the workspace is correctly configured' in this scenario?Sarah's statement refers to the core functionality of a monorepo tooling – automated dependency resolution. The workspace protocol allows packages to 'look up' dependencies in other parts of the repository based on declared ranges (e.g., `^4.17.21`). Incorrectly, David's response suggests manual pinning; this bypasses that automation and can lead to inconsistencies. The correct configuration ensures all dependent packages use the same, resolved version.
19 / 32
PR Description:
Subject: Add new User Authentication Service
This PR introduces a new service for user authentication. It utilizes the AuthService from the core monorepo and depends on lodash@4.17.21 for utility functions. The build process is failing with an error related to this dependency not being found. The team lead comments: 'Looks like we're missing a critical dependency declaration here.'
What does the team lead likely mean by 'we're missing a critical dependency declaration' in the context of the monorepo?The team lead is referring to how monorepos manage dependencies. When a package declares a dependency on another package within the monorepo, the tooling (like
pnpm or yarn workspaces) automatically resolves that dependency. Missing an explicit declaration means the resolver doesn't know about this dependency, leading to build failures; therefore, explicitly declaring it in the package.json is the correct action.20 / 32
Reviewer: 'The CI is failing because the new React component is trying to import utils.js from the `frontend` package, but that package doesn't have a public API! It's only meant for internal use within the frontend itself.' You are the developer working on the PR.
What does the reviewer likely mean by 'doesn't have a public API'?
The reviewer is highlighting a core principle of monorepos: code isolation and dependency management. Saying 'doesn't have a public API' correctly identifies that the
utils.js file was designed as an internal module *specifically* for use within the `frontend` package, preventing unintended dependencies and potential conflicts across the entire monorepo. Option A is close but focuses on hiding files rather than the intended purpose of a private API.21 / 32
During a code review, Alex says: "I've run `pnpm install` in this package, but the build is still failing and it's complaining about missing dependencies. It seems like the monorepo isn't resolving them correctly.". What does Alex likely mean when he refers to 'the monorepo not resolving them correctly'?
Alex is referring to a core concept of monorepos: dependency resolution. The monorepo tooling (like pnpm or yarn) manages the relationships between packages. When a package depends on another, the tooling must correctly identify and install all necessary dependencies, ensuring they are available across the entire repository. The incorrect option suggests a simple installation failure; this question focuses on the *tooling's* role in resolving those dependencies, rather than a user-level error.
22 / 32
Reviewer Liam comments: "The CI is failing after you added the `AuthService`. It's throwing an error about a missing dependency – `lodash`. I suspect this isn't explicitly declared in your package.json. What should I do next to investigate?"
Liam's comment highlights a common monorepo issue: implicit dependencies. The correct response is to check if `lodash` is explicitly declared. Running `pnpm install` might resolve some transient issues, but doesn't address the root cause of an unmet dependency. Options C and D represent potential solutions that don't directly address the immediate problem.
23 / 32
During a team standup, Ben says: "I'm having trouble with my feature branch. After merging, the build fails because it seems to be using an outdated version of `react`. I ran `pnpm install`, but it didn't fix it."
Ben's description strongly suggests a problem with monorepo package resolution or caching. Running `pnpm install` alone rarely solves issues related to inconsistent versions across packages within the monorepo. The lockfile (often managed by `pnpm`) is crucial for ensuring consistent dependency versions.
24 / 32
The API message clearly indicates a version conflict – a common challenge when working with monorepos. This highlights the importance of strict dependency versioning and careful consideration during package updates to avoid such conflicts. A simple syntax error is unlikely given the specific nature of the error.
25 / 32
The PR description points towards a potential failure of the monorepo's build system or dependency resolution. A corrupted lockfile or incorrect package manifests are common causes of this type of error, preventing `pnpm install` from correctly resolving all dependencies.
26 / 32
Sarah replies: 'That sounds like a problem with package isolation! The `frontend` packages shouldn't be directly using internal utilities. We need to ensure they're only consuming public APIs from the core monorepo. Can you refactor to use the AuthService directly?'
Sarah is pointing out a crucial principle: package isolation within a monorepo. Frontend packages should rely on publicly exposed APIs from the core, not directly accessing internal utilities. This ensures modularity and avoids dependency conflicts. Option 2 is incorrect because ignoring Sarah's advice will likely lead to more problems. Options A and C are partially correct but don't address the underlying architectural issue.
27 / 32
During a code review, Maya says: "I've run `pnpm install` but the build is failing and it's throwing an error about missing dependencies. I suspect there's an issue with how the monorepo is resolving dependencies for this package.". Which of the following best explains why Maya might be encountering this problem?
Maya is likely experiencing a dependency resolution issue. When using a monorepo, dependencies aren't always automatically propagated correctly; the package's own `package.json` needs to explicitly declare its requirements. Incorrect specifications here can lead to missing dependencies or version conflicts, preventing builds from succeeding – this is a common root cause of installation failures in monorepos.
28 / 32
In a Slack channel discussing a failing build, John writes: "I've added the `AuthService` from the core monorepo to my package. The CI is failing with an error indicating a missing dependency – `lodash`. I tried running `pnpm install`, but it didn't resolve the issue.". What is the MOST likely reason for this failure?
John's issue arises because he's attempting to use an internal utility (
lodash) from a package that is meant to consume a *public API* defined in the core monorepo. Monorepos enforce package isolation; packages should only depend on publicly available interfaces, not internal implementation details. This prevents unintended side effects and ensures consistent builds.29 / 32
A PR description states: "This PR introduces a new service for user authentication. It utilizes the `AuthService` from the core monorepo and depends on lodash@4.17.21 for utility functions.". What is the PRIMARY risk associated with this approach?
The primary risk lies in consuming internal utilities from the core monorepo. This creates a tight coupling between the package and the core, making it vulnerable to changes – any update to the core could break this package. Monorepos are designed for isolation; packages should only depend on public APIs.
30 / 32
During a code review, Maya says: "I've run `pnpm install` but the build is failing and it's throwing an error about missing dependencies. I suspect there's an issue with how the monorepo is resolving dependencies for this package.". Which of the following best explains why Maya might be encountering this problem?
Maya is likely experiencing a dependency resolution issue. When using a monorepo, dependencies aren't always automatically propagated correctly; the package's own `package.json` needs to explicitly declare its requirements. Incorrect specifications here can lead to missing dependencies or version conflicts, preventing builds from succeeding – this is a common root cause of installation failures in monorepos.
31 / 32
In a Slack channel discussing a failing build, John writes: "I've added the `AuthService` from the core monorepo to my package. The CI is failing with an error indicating a missing dependency – `lodash`. I tried running `pnpm install`, but it didn't resolve the issue.". What is the MOST likely reason for this failure?
John's issue arises because he's attempting to use an internal utility (
lodash) from a package that is meant to consume a *public API* defined in the core monorepo. Monorepos enforce package isolation; packages should only depend on publicly available interfaces, not internal implementation details. This prevents unintended side effects and ensures consistent builds.32 / 32
A PR description states: "This PR introduces a new service for user authentication. It utilizes the `AuthService` from the core monorepo and depends on lodash@4.17.21 for utility functions.". What is the PRIMARY risk associated with this approach?
The primary risk lies in consuming internal utilities from the core monorepo. This creates a tight coupling between the package and the core, making it vulnerable to changes – any update to the core could break this package. Monorepos are designed for isolation; packages should only depend on public APIs.
Frequently Asked Questions
What does the "Monorepo Tooling Vocabulary" exercise cover?
Practice English vocabulary for monorepo tooling concepts: workspaces, lockfiles, build systems, and shared configuration.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Monorepo Tooling Vocabulary"?
This exercise has 32 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Developer Toolchain exercises?
Browse the full Developer Toolchain hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.