Berry: [Bug] Workspaces not linking

[joshmeads]

• [ ] I'd be willing to implement a fix

Describe the bug

Can't add a workspace as a dependency to another. Not sure if I'm simply missing something but I've been through all the docs.

To Reproduce

Note: Sherlock prepare script link is broken in docs https://yarnpkg.com/advanced/scripts/actions/sherlock-prepare.js

Structure

- monorepo
  | - packages
    | - foo
    | - bar

yarn workspaces list --json

{"location":".","name":"monorepo"}
{"location":"packages/bar","name":"bar"}
{"location":"packages/foo","name":"foo"}

monorepo package.json

{
  "name": "base",
  "private": true,
  "workspaces": [
    "packages/*"
  ]
}

foo package.json

{
  "name": "foo",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
    "react": "^16.12.0",
    "bar": "workspace:1.0.0"
  }
}

bar package.json

{
  "name": "bar",
  "version": "1.0.0",
  "private": true
}

yarn workspace foo install

YN0000: ┌ Resolution step
➤ YN0001: │ Error: bar@workspace:1.0.0: Workspace not found (bar@workspace:1.0.0)
    at N.getWorkspaceByDescriptor (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:36:578058)
    at r.getCandidates (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:18:125280)
    at t.MultiResolver.getCandidates (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:24:41320)
    at t.MultiResolver.getCandidates (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:24:41320)
    at t.OverrideResolver.getCandidates (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:36:862484)
    at /Users/josh/n/lib/node_modules/yarn/bin/yarn.js:36:581640
    at /Users/josh/n/lib/node_modules/yarn/bin/yarn.js:36:857805
    at new Promise (<anonymous>)
    at e.exports (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:36:857787)
    at i (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:24:91764)
➤ YN0000: └ Completed in 0.01s
➤ YN0000: Failed with errors in 0.02s

Environment if relevant (please complete the following information):

• OS: OS X
• Node version: 13.7.0
• Yarn version: 2.0.0-rc.27

Additional context

I've tried scoping, running a real package code, multiple iterations of the workspace: syntax,

Have also tried without the workspace syntax and simply run

yarn workspace foo add [email protected]
➤ YN0000: ┌ Resolution step
➤ YN0001: │ HTTPError: barqweqwe@npm:1.0.0: Response code 404 (Not Found)
    at EventEmitter.<anonymous> (/Users/josh/n/lib/node_modules/yarn/bin/yarn.js:24:323118)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
➤ YN0000: └ Completed in 5.24s
➤ YN0000: Failed with errors in 5.24s

[arcanis]

I don't see anything wrong in your example unfortunately. My best guess is that bar isn't in packages (or isn't called bar - maybe an invisible character?).

I'll fix the Sherlock link, it should point to the following url. In the meantime, can you try to use Sherlock to reproduce the error you have? It'll be require less back-and-forth from both of us 😊

https://github.com/yarnpkg/berry/blob/master/scripts/actions/sherlock-prepare.js

[joshmeads]

It originally wasn't working on my production repo. I then made that dummy repo to verify.
Due to approaching progress deadlines I downgraded back to yarn 1 and everything worked fine with the above setup.

I'll try to find time this weekend to create a sherlock script! Thank you for fixing the link

[warrenfalk]

I ran into the same symptom.

You might have had a foo/yarn.lock.

For my scenario, yarn workspaces list from the monorepo root would list foo but the same command from inside foo lists nothing. Deleting foo/yarn.lock fixed everything.

I don't know if the OP's issue was the same as mine.

Troubleshooting this wasn't fun. It seems like something somewhere should have been warning about the yarn.lock being where it didn't belong (i.e. that it was in a project that is listed as a workspace).

I don't know how the yarn.lock got into the workspace project. I have not been able to come up with reproduction steps for that.

[ChiefORZ]

same problem here.

i even wrote the sherlock script yesterday:

``js repro const path = require(path); const {promises: {mkdir, readFile, writeFile, writeJson}} = require(fs`);

await packageJsonAndInstall({
"name": "root",
"private": true,
"workspaces": [
"frontend/*"
]
});

/* create shared module*/

await mkdir('frontend/common', { recursive: true });

await writeFile("frontend/common/index.js", index.j );

await writeJson("frontend/common/package.json", {
"main": "index.js",
"name": "@company/common",
"version": "0.0.1"
});

/* create an app module*/

await mkdir('frontend/app', { recursive: true });

await writeFile("frontend/app/index.js", `
const common = require('@company/common');

console.log(common);
`);

await writeJson("frontend/app/package.json", {
"dependencies": {
"@company/common": "workspace:*"
},
"main": "index.js",
"name": "@company/app",
"version": "0.0.1"
});

/* create another app module*/

await mkdir('frontend/app2', { recursive: true });

await writeFile("frontend/app2/index.js", `
const common = require('@company/common');

console.log(common);
`);

await writeJson("frontend/app2/package.json", {
"dependencies": {
"@company/common": "workspace:*"
},
"main": "index.js",
"name": "@company/app2",
"version": "0.0.1"
});

const version = await yarn('--version');
console.log('version', version);

await expect(yarn(workspace, @company/app2, install)).rejects.not.toThrow(
/Workspace not found/
);
```

but as it turned out, the sherlock test did not fail!!!
so i tried to reproduce it on my machine with a clean monorepo. and it kept on failing.

and i narrowed the error down - for me the problem were yarn config files(.yarn, .yarnrc.yml, yarn.lock) in my homedir.
so somehow yarn created some config files in my homedir and preferred those...

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolution faster). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label.