bestander
commented
7 years ago Can the randomness be reproduced on the same computer?
Closed bryanlarsen closed 6 years ago
bestander
commented
7 years ago Can the randomness be reproduced on the same computer?
bestander
commented
7 years ago @bryanlarsen, can you provide a script to reliably reproduce the issue?
bryanlarsen
commented
7 years ago @bestander, here's a reproduction: https://github.com/bryanlarsen/yarn-bug
bestander
commented
7 years ago Thanks
bryanlarsen
commented
7 years ago Sorry, that repo case isn't illustrating my problem. It does show funny behaviour, but not my problem. jq .version c/node_modules/gauge/package.json gives 2.7.4 in both cases.
bestander
commented
7 years ago A repro would help a lot
bryanlarsen
commented
7 years ago Finally got it to reproduce to what we're seeing in our code base. I've updated https://github.com/bryanlarsen/yarn-bug
bestander
commented
7 years ago Thanks, now how about a PR? :)
bestander
commented
7 years ago If I understand the problem correctly, running yarn install when there are linked dependencies may modify installed node_modules of the linked dependencies.
This needs some investigation for sure. In general this bug should be addressed with workspaces that we are working on now.
bryanlarsen
commented
7 years ago It's not just linked dependencies, that's just the easiest way to reproduce it. The basic problem is that the node_modules directory layout is not stable. Another way to do it is to have an optional dependency. If the optional dependency installs, the node_modules layout can be considerably different than when it doesn't install. Or an upgrade might totally rejigger the node_modules layout. Although not as serious as the linked dependency problem, it really plays havoc with Makefile auto dependencies.
bryanlarsen
commented
7 years ago But workspaces look awesome. lerna doesn't work for us but it does look like workspaces will. I fully agree with tabling this issue until after workspace support is released.
bestander
commented
7 years ago Yarn should install the same structure of node_modules no matter if package is actually installed or not.
E.g. the layout will be the same when you do yarn install and yarn install --production although in the --production install node_modules will have some dev-only packages missing.
Yarn can restructure all node_modules with an upgrade, e.g. when a package becomes more common and it gets moved to the root of node_modules but this is by design.
On the other hand Yarn promises that the structure will be the same every time you run yarn install, no matter what was inside node_modules previously and if it is not so we need to fix it.
BYK
commented
6 years ago This should be fixed by #4757. If not please reopen.
PS: I cannot use the repro repo because it has a folder named con in it which is an invalid folder name on Windows. Not sure if you did this on purpose :D
Do you want to request a feature or report a bug?
Seems like a bug, although this behaviour could be by design.
What is the current behavior?
Conflicting nested dependencies are not always installing in the same location. So if yarn decides it needs to install foo@1 and foo@2, it could install node_modules/foo@1 & node_modules/bar/node_modules/foo@2 or node_modules/foo@2 & node_modules/bat/node_modules/foo@1.
Why this matters: we autogenerate a .deps file that we can hand to make. If files can move when somebody runs yarn, this really confuses make. The Makefile knows it has to regenerate the .deps file when package.json or yarn.lock change, but if they don't it gets confused.
If the current behavior is a bug, please provide the steps to reproduce.
package.json & yarn.lock attached below. The specific package that is giving us problems is gauge, which is required by npmlog, which our dependencies require different versions of.
What is the expected behavior?
Given two installations with the same yarn.lock, all conflicting dependencies should be installed in the same place in node_modules.
Please mention your node.js, yarn and operating system version.
node 4.2.6 yarn 0.21.3
package.json:
yarn.lock: