workspaces install fails with private dependencies

[ianstormtaylor]

Do you want to request a feature or report a bug?

Bug.

What is the current behavior?

Right now yarn install fails if you have a private monorepo using workspaces and a package has a dependency on a private local package. It tries to find the private dependency in the registry, but it doesn't exist there, and then it fails with:

$ yarn
yarn install v1.3.2
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
error Couldn't find package "********" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

If the current behavior is a bug, please provide the steps to reproduce.

If you have a private monorepo with a workspaces structure like:

root/
  packages/
    private-module-a/
    private-module-b/

And the private-module-a has a dependency on private-module-b.

error Couldn't find package "private-module-b" on the "npm" registry.

This is an issue in private monorepos, where you'll end up with lots of packages that are private to the repo itself, but that depend on each other. It never comes up with public monorepos because I don't think it makes sense for a public package to have a private dependency.

What is the expected behavior?

Yarn should see that one of the dependencies is already local in the workspace, and not try to install it from the registry at all, just symlink it.

Please mention your node.js, yarn and operating system version.

$ node -v
v8.9.4
$ yarn -v
1.3.2

Here's a similar Lerna issue: lerna/lerna#998

I tried to search through the issues to see if this was solved already, but couldn't find anything recent that was detailing this exact problem, so figured I'd open it. Thanks!

[rally25rs]

I seem to be unable to reproduce:

~/Projects/test 🐒   cat packages/package-a/package.json
{
  "name": "package-a",
  "version": "0.0.1",
  ...

~/Projects/test 🐒   cat packages/package-b/package.json
{
  "name": "package-b",
  "version": "0.0.1",
  "dependencies": {
    "package-a": "*",
  ...

~/Projects/test 🐒   rm -rf node_modules/

~/Projects/test 🐒   yarn
yarn install v1.3.2
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
[3/5] 🚚  Fetching packages...
[4/5] 🔗  Linking dependencies...
[5/5] 📃  Building fresh packages...
✨  Done in 10.98s.

I'm also not quite sure what you mean with public vs private. All the dependencies are treated as local links, so public vs private is not a thing that should matter, as none of hte modules need to be published. If you ls -l the node_modules directory you can see that the installed dependencies are just symlinks to the packages/ directory:

~/Projects/test 🐒   ls -l node_modules/
...
lrwxr-xr-x    1 jvalore  MYORG\Domain Users     15 Jan 15 15:42 package-a -> ../packages/package-a
...

Would it be possible to share your package.json's, or make a minimal reproduction?

[ianstormtaylor]

@rally25rs you're absolutely right, I'm an idiot. Thank you for the follow up. Turns out my package-a actually looked like:

package-a/
  src/
    index.js
    package.json

Instead of:

package-a/
  src/
    index.js
  package.json

So it wasn't finding a package.json for that package in the workspace, and I didn't spot the difference in the sidebar.

Thank you for the quick reply and gut check!

[rally25rs]

Hah, oops, that would do it 😄
Glad you found the issue!

[valerybugakov]

@ianstormtaylor @rally25rs is it possible to have core workspace with multiple versions which will be used by a and b without publishing to npm?

For example: a depends on core@1.0.0 and b depends on core@1.0.1. If I try this config I'm getting the same error:

error Couldn't find package "core" on the "npm" registry.

[valerybugakov]

Btw it works as expected if core is published to npm.
Should yarn resolve versions using Git in similar way if shared package is not published?

Documentation mentions Github deps resolution here:
https://yarnpkg.com/lang/en/docs/workspaces/#toc-limitations-caveats

[moghammed]

I also noticed that the folder that package-a resides in must also be called package-a, or you get the same error.

[softmarshmallow]

Mine was referencing the wrong name.
"@sub.domain.com/a"

instead of
"@domain.com/a"

[molszanski]

please note, that you should name your "experimental" versions:

{
  "name": "something",
  "version": "0.4.0-alpha", // `alpha-0.4.0` will not produce this err
}

[mkermani144]

I had issues with wrong version number. (e.g. I was adding a local dependency of version "1.0.0" while the package has another version, say "0.0.1".)

[kiastorm]

I had an unneeded package.json file hiding in the parent folder

Documents/dev/my-app/package.json

Documents/dev/package.json <-- This was confusing yarn. I deleted it and made progress

[koljam]

For others coming this way: For me the solution was to update yarn. For some reason i still had 1.x on my machine.

npm install -g yarn
yarn set version stable