nohoist in Workspaces

  • 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…

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 is the attempt to provide an easy-to-use mechanism, natively supported by yarn, for enabling workspaces to work with otherwise incompatible libraries.

We hope this feature would ease the pain for monorepo developers and strike a balance between efficiency (hoisting as much as possible) and usability (unblock the libraries who haven’t been adapted for workspaces).

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 a standalone project, the dependency tree can be reduced like this:

. Most module crawlers/loaders/bundlers can locate modules pretty efficiently by traversing down the “node_modules” tree from the project root.

Then came the monorepo project, which introduced a new hierarchical structure that is not necessary linked by “node_modules”. In such project, modules could be scattered in multiple locations:

. This optimization becomes even more prominent when considering these packages will most likely be dependent on each other (the main reason to have the monorepo), i.e. higher degree of redundancy.

While it might appear that we can access all modules from the project’s root node_modules, we often build each package in its local project, where the…

nohoist in Workspaces