At some point in the past the decision was done to have no hoisting limits and rely on yarn to decide which versions of dependency get placed in the root node_modules.
The pro's of this would be: smaller node_modules on disk-space, easier syncing of same dep versions across the packages.
The benefit of setting the nmHoistingLimits to 'workspaces' would be:
the dependency are more clearly defined per package
there are no confusing dependency conflicts happening because of hidden relying on a not explicitely defined dependency
easier to handle updating specific versions for specific packages and not break the other ones
Downsides are:
increased disk-space needed
More overhead in managing the dependencies
Since we also host some legacy (or barely used) packages in the mono-repo we already almost never define root package dependency so having workspaces as a limit is not that strange.
So either on of the below is a solution
[ ] - set limits to workspaces
[ ] - keep no-limit and make a decision on the legacy packages if they should be in mono-repo
[ ] - Lerna (which was before unmaintained and deprecated) is moved to new maintainer, and seems to be active in development. maybe we want to consider using a dependency manager (considering the mono-repo keeps growing over-time and managing dependency will be a actuall increasing overhead headache)
Description
At some point in the past the decision was done to have no hoisting limits and rely on yarn to decide which versions of dependency get placed in the root node_modules. The pro's of this would be: smaller node_modules on disk-space, easier syncing of same dep versions across the packages.
The benefit of setting the nmHoistingLimits to 'workspaces' would be:
Since we also host some legacy (or barely used) packages in the mono-repo we already almost never define root package dependency so having workspaces as a limit is not that strange.
So either on of the below is a solution