-
Notifications
You must be signed in to change notification settings - Fork 15
Workaround for yarn link bug #10
Comments
@OliverUv would be cool if you come up with a workaround. But what I also noticed is that yarn does not detect if a dependency is linked. I.e. if you have "package-a": "*" in you package.json and package-a was linked previously with |
That seems to be described here yarnpkg/yarn#1297 I get 156 open issues with the word "link" in the yarn repo. Guessing they're a bit swamped at the moment, and that I'll report this bug on their issue tracker, and won't bother using yarn until things have improved. Guess we're back to 2x build times on our CI system with slow as molasses Chinese npm mirrors :( Want me to add a warning to the readme about the brokenness of |
@OliverUv Sounds good, thanks. And let's hope yarn will fix the linking process so that it is compatible with npm - yarn is a great tool. |
Closing since there isn't much more to be done than wait. |
So I looked into that test error you found in Pull #9
I reset everything locally, then added
.only
to the yarn test, and got the same result you did. Yarn does set up symlinks correctly, but it does not automatically runyarn install
for the linked modules. Since the links would always link back to theshared_modules/*
directories, the test suite would detect the lodash folder installed by the tests run with npm previously. I suppose the same thing must have happened on Travis.Since yarn aims to mirror the functionality of npm, this must be considered a bug on their side.
Would you be interested in me implementing a workaround for it in this project? I would gate it behind a
--yarn-workaround-force-install
flag (since my use case scenario for this is all stuff run in CI systems, the long flag name is acceptable)The text was updated successfully, but these errors were encountered: