Currently, monorepos rely on an extends property in each sub-project. This was done for a few reasons:
to avoid needing to crawl up the file tree to an undetermined point looking for the closest package.json with a volta field
to allow sub-projects to override the main configuration
to ensure volta wasn't tied to something like "git root" for projects that don't use git.
However, I think we can do better!
The spec for package.json has added support for monorepo projects that publish multiple packages to the repository field. This field may now be an object with the keys typeurl and directory. When present, directory is a relative path within the repository pointing to the directory the current package.json is within. Ergo, it is also tells us precisely where to look for the root package.json file.
I'm proposing that we utilize this field by default, when present, unless another volta configuration is present, we find the root package.json and examine it for a volta configuration.
This change would thereby also minimize a risk that the current approach introduces for projects using workspaces. In such projects, mixing yarn/npm/pnpm versions when using workspaces can lead to some serious install problems when dependency versions are shared.
Currently, monorepos rely on an
extendsproperty in each sub-project. This was done for a few reasons:However, I think we can do better!
The spec for
package.jsonhas added support for monorepo projects that publish multiple packages to therepositoryfield. This field may now be an object with the keystypeurlanddirectory. When present,directoryis a relative path within the repository pointing to the directory the currentpackage.jsonis within. Ergo, it is also tells us precisely where to look for the rootpackage.jsonfile.I'm proposing that we utilize this field by default, when present, unless another volta configuration is present, we find the root package.json and examine it for a volta configuration.
This change would thereby also minimize a risk that the current approach introduces for projects using
workspaces. In such projects, mixing yarn/npm/pnpm versions when using workspaces can lead to some serious install problems when dependency versions are shared.