State of git workspaces?

[Nkmol]

This might be a continuation on the topic of npm/npm#2974, where the main stance was to not support monorepos as the focus was to not add more features/complexity at that time. With the introduction of workspaces, I have the feeling this stance has slightly changed.

For unpublished packages, we already have the options to install them through a remote URL: npm install <git remote url>. However, this method does not work when the repository is a monorepo where no root-project package.json exists, currently resulting in the following error:

npm ERR! enoent ENOENT: no such file or directory, open '/Users//.npm/_cacache/tmp/git-cloneThbqCx/package.json'

To extend the work of workspaces, it would be great if we could integrate workspace in the URL protocol, using the top-level workspace package.json to resolve the workspace name. Seeing it has been discussed before, I do wonder what the current opinions are about this and if this is something that does fit with NPM's philosophy nowadays.

---

As a reference, Yarn currently supports this through a URL fragment value of workspace=<name>

• Reference in their URL snaps: https://github.com/yarnpkg/berry/blob/master/packages/plugin-git/tests/__snapshots__/gitUtils.test.ts.snap
• The PR adding this: Implements Git Workspaces yarnpkg/berry#1261

[kylerneva]

npm already covers most of this use case with workspaces, which rely on a root package.json to resolve and link packages correctly. Extending git URLs to target a specific workspace would introduce additional complexity in install behavior and URL semantics. The current approach favors explicit workspace configuration rather than implicit resolution through install URLs.