Does it make sense to have yarn.lock for each workspace? And, why is Yarn Workspaces + Lerna a thing?
Yarn workspaces and yarn.lock
Yarn workspaces are native support for monorepo by yarn. You may have multiple packages under the same repo, but yarn workspaces allow you to install all dependencies in your root package. Therefore, you'll also have only one yarn.lock under root and having a yarn.lock per workspace is not yet supported.
You may wonder why you would want multiple yarn.lock even though all dependencies are installed under root. To name one example, this should not be the only one, in the project I work on one of the packages is a template and is used to bootstrap generate similar projects. We want to maintain consistent behavior across those generated projects so we want yarn.lock inside that template. There are ways to go around this, i.e., to not include that package in the workspaces, or to do this step manually elsewhere, but at this stage having each workspace maintain its own yarn.lock while still having native monorepo package management is not supported.
To name a few common practices, Docusaurus, Nextjs, Gatsby all use yarn workspaces and they all have only one yarn.lock in their repo. Although Gatsby starters which are meant for a similar purpose with the generator I work on, each is a standalone repo and keeps yarn.lock inside.
More on monorepo approaches
There are other monorepo approaches. One popular option is to use Lerna. Lerna existed before yarn workspaces and has many commands to help with your monorepo management. It is possible and good fit to use Lerna on top of yarn workspaces and this is once again adapted by all of Docusaurus, Nextjs, and Gatsby. Here's is an amazing article explaining this Why Lerna and Yarn Workspaces is a Perfect Match for Building Mono-Repos – A Close Look at Features and Performance and the article is paired with a great GitHub repo demonstrating different mono repo approaches.
bolt is another monorepo utility library inspired by yarn workspaces.
Should we use monorepo
Some quick notes only, I don't have a thorough idea yet.
It's very handy since we have one set of node_modules. But it can cause undesired consequences as any one problem may affect all your packages. This can be particularly confusing when each package is an standalone app. It does seem to be a nice fit for library development, though.