[Bug?]: Regression Yarn 3.0 creates self-reference link for each workspace
See original GitHub issueSelf-service
- I’d be willing to implement a fix
Describe the bug
Yarn 3.0 creates a self-reference link for each workspace which does not happen with v2.4.2
To reproduce
const fs = require('fs')
fs.writeFileSync('.yarnrc.yml', 'nodeLinker: node-modules \r\n nmHoistingLimits: workspaces')
await packageJson({ name: 'root', workspaces: ['packages/*'] })
await packageJson({ name: 'package-a' }, { cwd: 'packages/package-a' })
await yarn('install')
expect(fs.existsSync('packages/package-a/node_modules/package-a')).toBe(false);
Environment
System: OS: macOS 11.5 CPU: (12) x64 Intel® Core™ i7-9750H CPU @ 2.60GHz Binaries: Node: 16.5.0 - /private/var/folders/p4/8995l80n0m10v308tf59n7xc0000gp/T/xfs-30c2485c/node Yarn: 3.0.0 - /private/var/folders/p4/8995l80n0m10v308tf59n7xc0000gp/T/xfs-30c2485c/yarn npm: 7.19.1 - ~/.nvm/versions/node/v16.5.0/bin/npm
Additional context
➜ yarn -v
2.4.2
➜ tree
.
├── node_modules
├── package.json
├── packages
│ └── package-a
│ └── package.json
└── yarn.lock
3 directories, 3 files
➜ yarn set version latest
➤ YN0000: Downloading https://github.com/yarnpkg/berry/raw/master/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-3.0.0.cjs
➤ YN0000: Done in 1s 460ms
➜ yarn install
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: Done in 0s 103ms
➜ yarn -v
3.0.0
➜ tree
.
├── node_modules
├── package.json
├── packages
│ └── package-a
│ ├── node_modules
│ │ └── package-a -> ..
│ └── package.json
└── yarn.lock
5 directories, 3 files
You can see the new symbolic link created.
I did not find this behavior as intended in the breaking changes of Yarn 3.0. I’m really sorry if I missed it.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Yarn 3.0 - Hacker News
I used to use yarn all the time until I tried pnpm. The speed is amazing, and as a traveler I love that...
Read more >pretty-format | Yarn - Package Manager
Serialize application-specific data types with built-in or user-defined plugins. Installation. $ yarn add pretty-format ...
Read more >Changelog - Highcharts
Check out the changelog for Highcharts, Highcharts Stock, Highcharts Maps, and Highcharts Gantt. Learn all about old and new releases, features and options ......
Read more >Issues workflow - GitLab Docs
Please submit bugs using the 'Bug' issue template provided on the issue ... If you want to create something yourself, consider opening an...
Read more >tpi - River Thames Conditions - Environment Agency - GOV.UK
501 km per hr? ... Bugunun saraylisi 20 tek parca, Tlv1117-33cdcyr pdf, Yapay oyun trailer, ... Stable isotopes of holmium, Create your ideal...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

An option to disable the self-references in yarn would help me work around an issue I’m having with babel. An
ELOOP: too many symbolic links encounterederror occurs when using babel even though I’ve specified--ignore "**/node_modules". The error occurs before any babel config is loaded.@loremaps It is intended, I’m sorry it caused trouble for you. Not creating self-references can be seen as a bug, since it will deviate from the pnp linker results, and the linkers should behave as close as achievable. I understand that sometimes self-references are not wanted, probably having a setting to disable them globally or on per-workspace basis would be the way to go.