Decision: Choosing Monorepo approach and tooling

📔 What is it - Choosing the right Monorepo tool and features for the boilerplate

⏰ Status - Open for discussions

📁 Corresponding discussion - Here

🎯Bottom-line: our recommendation - TBD

📊 Detailed comparison table

*For some lacking features there is a community package that bridges the gap; For workspace, we evaluated whether most of them support a specific feature****

	nx	Turborepo	Lerna	workspace (npm, yarn, pnpm)
Executive Summary
Community and maintenance	Huge eco-system and commercial-grade maintenance	Trending, commercial-grade maintenance	Not maintained anymore	Solid
❗Encourage component autonomy	Packages are highly coupled	Workflow is coupled	npm link bypasses the SemVer	Minor concern: shared NODE_MODULES on the root
Build speed	Smart inference and execution plan, shared dependencies, cache	Smart inference and execution plan, shared dependencies, cache	Parallel tasks execution, copied dependencies	Shared dependencies
Standardization	Non standard Node.js stuff: One single root package.json by default, TS-paths for linking	An external build layer	An external build layer	An external package centralizer
Tasks and build pipeline
Run recursive commands (affect a group of packages)	Yes	Yes	Yes	Yes
❗️Parallel task execution	Yes	Yes	No	Yes* (Yarn & Pnpm)
❗️Realize which packages changed	Yes	Yes	Yes	No
❗️Realize packages that are affected by a change	Yes both through package.json and code	Yes through package.json	None	None
Ignore missing commands/scripts	No	Yes	Yes	Yes
❗️In-project cache - Skip tasks if local result exists	Yes	Yes	No	No
Remote cache - Skip tasks if remote result exists	Yes	Yes	No	No
Visual dependency graph	Yes	Yes	Partially, via plugin	No
❗️Smart waterfall pipeline - Schedule unrelated tasks in parallel, not topologically	Yes	Yes	No	No
Distributed task execution - Spread tasks across machines	Yes	No	No	No
Locally linking packages
❗️Is supported	Partially Achieved through TS paths	No Relies on workspaces	Yes	Yes
How	❗️Via TypeScript paths and webpack	Relies on workspaces	Symlink	Symlink
❗️Can opt-out?	Yes By default local packages are linked	-	No	Partially Pnpm allows preferring remote packages, Yarn has a [focused package](https://classic.yarnpkg.com/blog/2018/05/18/focused-workspaces/) option which only works per a single package
Link a range - only specific versions will be symlinked	No	-	No	Some Yarn and Pnpm allows workspace versioning
Optimizing dependencies installation speed
Supported	Yes Via a single Root package.json and NODE_MODULES	Yes Via caching	No Can be used on top of yarn workspace	Yes Via single node_modules folder
Retain origin file path (some module refers to relative paths)	Partially NODE_MODULES is on the root, not per package	Yes	Not relevant	Partially Pnpm uses hard link instead of symlinks
Keep single NODE_MODULES per machine (faster, less disc space)	No	No	No	Partially Pnpm supports this
Other features and considerations
Community plugins	Yes	No	Yes	Yes
Scaffold new component from a gallery	Yes	None	None	None	Create a new package to the repo	Built it code genreation with useful templates	None, 3rd party code generator can be used	None, 3rd party code generator can be used	None, 3rd party code generator can be used
Adapt changes in the monorepo tool	Supported via nx migrate	Supported via codemod	None	None
Incremental builds	Supported	Supported	None	None
Cross-package modifications	Supported via nx generate	None	None	None

__

Ideas for next iteration:

• Separate command execution and pipeline section
• Stars and popularity
• Features summary
• Polyrepo support