Learn English vocabulary for package dependency resolution: dependency tree, peer dependencies, hoisting, phantom dependencies, workspaces, and resolution algorithms.
0 / 5 completed
1 / 5
A 'dependency tree' in package management represents:
When you install lodash, lodash may depend on package A, which depends on package B. The dependency tree maps all these nested relationships. Deep trees with conflicting version requirements are the core challenge of dependency resolution.
2 / 5
'Peer dependencies' in a package's package.json signal that:
Peer deps say 'I expect the host project to provide this package.' React plugin packages use peer deps for react — they don't bundle React, they expect the project using them to have React installed. This avoids duplicate React instances.
3 / 5
'Hoisting' in npm's node_modules means:
npm hoists packages to reduce duplication — if package A and package B both need lodash@4.17.21, npm places one copy at the root node_modules level rather than two nested copies. Hoisting is why you can sometimes accidentally use packages you haven't explicitly installed.
4 / 5
A 'phantom dependency' problem occurs when:
If package A hoists lodash into your root node_modules, you can import lodash in your code even without listing it. But if A ever stops depending on lodash, it disappears from your node_modules and your code breaks — this is a phantom dependency bug.
5 / 5
'Workspaces' in npm, Yarn, and pnpm allow developers to:
Workspaces link packages within a monorepo locally — package B can import from package A without publishing to the registry. The package manager hoists shared dependencies to the root and symlinks local packages, enabling monorepo development.