> With Yarn Workspaces, installing packages across workspaces becomes faster and lighter. Additionally, it prevents package duplication across workspaces and al

> With Yarn Workspaces, installing packages across workspaces becomes faster and lighter. Additionally, it prevents package duplication across workspaces and also makes it possible to create links between directories that depend on each other, ensuring that all directories are consistent in the monorepo. Nice that they included a footnote about pnpm. Makes me want to write a counter article about using pnpm instead. pnpm is faster than yarn 1 (variable with yarn 2, depending on use) and workspaces are just easier. Lest we forget hoisting and dependency dedupe, which is far and away superior with pnpm. My pnpm + TS setup is as follows: - /shared/ directory at root that contains tsconfig.base.json, tsconfig.eslint.json, tsconfig.json (which is only symlinked to, has relative settings for the directories it's linked into) - tsconfig.json at the root, extending shared/tsconfig.base.json, including all things that an editor might care about - /packages/ (or /services/) at the root - /packages/{package}/tsconfig.json -> symlinked to -> /shared/tsconfig.json This setup allows various editors to validate code in any directory that might have TS (and JS!), editor plugins that use ESLint to have a TS config reference, and allows deployment and/or build processes to operate on individual entities in packages|services without having to build the world. Note that this isn't ideal in monorepos where you want to build the world. In monorepos where I have packages and services, for example, and the services are dependent on the packages build built, I leverage pnpm's recursive script ability with filtering to build some of the world, but not all. (Happy to answer questions on pnpm monorepos)