- First, let’s take a quick tour on how hoist work in standalone projects: – – To reduce redundancy, most package managers employ some kind of hoisting scheme to extract and flatten all dependent modules, as much as possible, into a centralized location.
- In such project, modules could be scattered in multiple locations: – – yarn workspaces can share modules across child projects/packages by hoisting them up to their parent project’s node_modules: .
- Consequently, workspaces developers often witness “module not found” related errors when building from the child project: – – For this monorepo project to reliably find any module from anywhere, it needs to traverse each nodemodules tree: *“monorepo/nodemodules”* and .
- There are indeed many ways library owners can address these issues, such as multi-root, custom module map, clever traversing scheme, among others… However, – – It is frustrating when a solution worked for a standalone project only fell short in the monorepo environment.
- Module path is a virtual path of the dependency tree, not an actual file path, so no need to specify “node_modules” or “packages” in the nohoist pattern.
As wonderful as yarn workspaces are, the rest of the community hasn’t yet fully caught up with the monorepo hoisting scheme. The introducing of the nohoist i…
Continue reading “nohoist in Workspaces”