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
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>
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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-projectpackage.json
exists, currently resulting in the following error: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>
Beta Was this translation helpful? Give feedback.
All reactions