You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently, monorepos rely on an
extends
property in each sub-project. This was done for a few reasons:However, I think we can do better!
The spec for
package.json
has added support for monorepo projects that publish multiple packages to therepository
field. This field may now be an object with the keystype
url
anddirectory
. When present,directory
is a relative path within the repository pointing to the directory the currentpackage.json
is within. Ergo, it is also tells us precisely where to look for the rootpackage.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.The text was updated successfully, but these errors were encountered: