12/24/2023 0 Comments Yarn workspaces add packageTurns out there is, and is conveniently called “nohoist”, which has also been demonstrated in other monorepo tools like lerna. Is there a simple yet universal mechanism that can allow these incompatible libraries working in the monorepo environment? The ideal solution lies in addressing the underlying libraries, but the reality is far from perfect and we all know that our projects can’t wait… What is “nohoist” ? It is frustrating when a solution worked for a standalone project only fell short in the monorepo environment. But it won’t help the bootstrap process like react-native init or create-react-native-app, which has no access of any such tooling before the app is created/installed. the bootstrap problems: for example, react-native has provided a way to configure multi-root through.A single non-adapted package deep down the tool chain could render the whole tool useless. However, that also means the complex tool chain is only as strong as the weakest link. the weakest link problem: javascript is great thanks to the massive 3rd-party libraries.not all the 3rd party libraries have the resource to adapt for monorepo environment.There are indeed many ways library owners can address these issues, such as multi-root, custom module map, clever traversing scheme, among others… However, can’t find module from “package-1” (unaware of the module tree above in “monorepo”)įor this monorepo project to reliably find any module from anywhere, it needs to traverse each node_modules tree: “monorepo/node_modules” and “monorepo/packages/package-1/node_modules”.can’t find module from project root “monorepo” (not able to follow symlink).In addition, not all crawlers traverse symlinks.Ĭonsequently, workspaces developers often witness “module not found” related errors when building from the child project: 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 modules might not be visible under its own node_modules. 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. Yarn workspaces can share modules across child projects/packages by hoisting them up to their parent project’s node_modules: monorepo/node_modules. In such project, modules could be scattered in multiple locations: Then came the monorepo project, which introduced a new hierarchical structure that is not necessary linked by “node_modules”. Most module crawlers/loaders/bundlers can locate modules pretty efficiently by traversing down the “node_modules” tree from the project root. With hoist, we were able to eliminate duplicate and while preserving version variation and maintaining the same root package-1/node_modules. In a standalone project, the dependency tree can be reduced like this: 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. What is the problem ?įirst, let’s take a quick tour on how hoist work in standalone projects: 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). 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. As wonderful as yarn workspaces are, the rest of the community hasn’t yet fully caught up with the monorepo hoisting scheme.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |