Workspaces hoisting limits

[L03TJ3]

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:

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

[L03TJ3]

@johnsmith-gooddollar @sirpy please comment on your thoughts which way to go for this

for now I have opened this PR where we use workspaces limit: https://github.com/GoodDollar/GoodWeb3-Mono/pull/109

[L03TJ3]

Released