Yarn
Fleetingdeduplicate with hardlinks and –link-duplicates
yarn install –link-duplicates
Create hardlinks to the repeated modules in node_modules.
workspace
-
External reference: https://classic.yarnpkg.com/en/docs/workspaces
Allows using only one node_modules shared among sub projects (called workspaces). symlinks will be created to link workspace together and thus allowing more practical way of linking workspaces.
dependencies can be linked together, which means that your workspaces can depend on one another while always using the most up-to-date code available. This is also a better mechanism than yarn link since it only affects your workspace tree rather than your whole system.
Why would you want to do this?
- Your dependencies can be linked together, which means that your workspaces can depend on one another while always using the most up-to-date code available. This is also a better mechanism than yarn link since it only affects your workspace tree rather than your whole system.
- All your project dependencies will be installed together, giving Yarn more latitude to better optimize them.
- Yarn will use a single lockfile rather than a different one for each project, which means fewer conflicts and easier reviews.
private: true is required! Workspaces are not meant to be published
when using workspaces, create symlinks in workspace node_modules to root node_modules
-
External reference: https://github.com/yarnpkg/yarn/issues/5469
you can use –link-duplicates flag to hardlink duplicated modules, so even without symlinks you can still save significant disk space
I think you’re right that –link-duplicates is what I’m looking for.
how to use “nohoist” in Yarn workspaces?
-
External reference: https://classic.yarnpkg.com/blog/2018/02/15/nohoist/
-
External reference: https://medium.com/@levente.balogh/how-to-use-nohoist-in-yarn-workspaces-d9457a1ad430 Two make a whole workspace no use the hoisting mechanism, you can provide the following in your workspace package.json (not the root one)
"workspaces": { "nohoist": [ "*" ] },Altenatie
rest of the community hasn’t yet fully caught up with the monorepo hoisting scheme
where you don’t want your underlying package dependencies to be hoisted to the root level
— https://medium.com/@levente.balogh/how-to-use-nohoist-in-yarn-workspaces-d9457a1ad430
yarn workspaces can share modules across child projects/packages by hoisting them up to their parent project’s node_modules: monorepo/node_modules
dealing with intra dependencies
note the fact that /workspace-a is aliased as /node_modules/workspace-a via a symlink. That’s the trick that allows you to require the package as if it was a normal one
beware the hoisting
For instance, if you are working on a project that is a workspace. Then its node_modules will be partially filled. You will not be able to get a fully running project by simply copy/pasting the workspace folder.
The package layout will be different between your workspace and what your users will get (the workspace dependencies will be hoisted higher into the filesystem hierarchy). Making assumptions about this layout was already hazardous since the hoisting process is not standardized, so theoretically nothing new here.
careful when publishing packages in a workspace. If you are preparing your next release and you decided to use a new dependency but forgot to declare it in the package.json file, your tests might still pass locally if another package already downloaded that dependency into the workspace root. However, it will be broken for consumers that pull it from a registry, since the dependency list is now incomplete so they have no way to download the new dependency. Currently there is no way to throw a warning in this scenario.
plug and play
-
External reference: https://classic.yarnpkg.com/en/docs/pnp
way regular installs work is simple: Yarn generates a node_modules directory that Node is then able to consume. In this context, Node doesn’t know the first thing about what a package is: it only reasons in terms of files. “Does this file exist here? No? Let’s look in the parent node_modules then. Does it exist here? Still no? Too bad… parent folder it is!” - and it does this until it matches something that matches one of the possibilities.
what Plug’n’Play (abbreviated PnP) is. Instead of generating a node_modules directory and leaving the resolution to Node, we now generate a single .pnp.js file and let Yarn tell us where to find our packages