-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yarn is deleting symlinks in node_modules that it doesn't own #5709
Comments
yarn deletes all files and directories under node_modules that don't belong to the currently installed packages. This is part of the design. It does work differently than npm's pruning/cleaning of extraneous files. For comparison, npm will only delete extraneous directories in My personal opinion is that npm is incorrect. @yarnpkg/core think this should be "closed / as designed" or a bug due to "npm compatibility"? |
This isn't quite accurate, yarn doesn't touch symlinked directories regardless of whether or not they're in
I personally disagree here. node (and tooling) is setup so that AFAIK yarn doesn't actually have a use-case for symlinking individual files in |
I did find this comment in the code:
I suspect it works the way it does because what if:
The symlink
if so then this is a recent change then. npm used to auto-prune on install. npm/npm#16853 maybe npm just doesn't auto prune symlinks? that might make sense, since npm doesn't have a |
I see your point about yarn keeping things tidy and agree, but it's frustrating that there isn't a way to tell it that it doesn't own something. For instance if I put:
I'd hope that yarn would ignore both of these since it doesn't understand them. Instead it treats these as just unresolved versions against the npm registry and either throws an error if npm doesn't have the package or prompts for a version # from npm. Maybe this is the more relevant discussion. Nit about symlinks -- since yarn doesn't have symlinks to files, only package folders, I don't see why it should prune them. But we also create directories in |
Yes it would, and probably should. If something doesn't match the package manager expected output, it should be removed, otherwise the guarantee that
No, it should fail the installation. If something causes a package not to be installed (such as an unknown protocol), the whole installation is bogus, since the requested dependencies won't be there, breaking the contract. If you want to use custom protocols, then put them in another key than
They shouldn't exist in the first place 🙂 |
@arcanis -- This goes back to my point that node owns
Sure, except that yarn would still delete the files generated. Not having an escape hatch seems unnecessarily controlling. |
@markkahn - apparently you and the Yarn team have clearly differing opinions there. For the strong consistency guarantees that we want Yarn to deliver, we have chosen to implement this behavior.
Is |
Maybe This would allow for better interop between tooling. |
@rally25rs Not arguing with a point, that If there is a symlink in a node_modules, that leads to an external directory, |
Facing the same problem. I have a postinstall() {
local repo_root="$(determine_repo_root)"
ln -sf $repo_root "$repo_root/node_modules/@"
} which leads to: ls -la | head
lrwxr-xr-x 1 farewell staff 51 Oct 1 13:57 @@ -> /Users/farewell/Workflow/Projects/Dash/corp-dash-ui After running my |
Can you make repro project that we can just checkout to try out? Thanks 🙂 |
@arcanis, I created a repo for my case and found an interesting thing. I wrote a steps for reproducing in README, but in short, the problem can be observed if and only if the name of symlink starts with |
Oooh! That totally makes sense - if something starts with an @ we assume
it's an npm scope, in which case we have to recurse inside to find out the
actual package folders. So from Yarn point of view, @/sources is a package
called "sources" from the scope "@".
Three solutions :
- special case "@" in Yarn
- don't recurse if the scope folder is a symlink
- ask users not to create such symlinks
…On Wed, Oct 3, 2018, 9:25 AM Eli Shvartsman ***@***.***> wrote:
@arcanis <https://github.com/arcanis>, I created a repo
<https://github.com/shvar/yarn-install> for my case and found an
interesting thing.
I wrote a steps for reproducing in README, but in short, the problem can
be observed if and only if the name of symlink starts with @. Sounds like
some internal policy, that we missed? 😕
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5709 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA_WaxSv6NmqENQ_L4P-siGWFtdjHVoaks5uhHSOgaJpZM4TeVlF>
.
|
@arcanis, if I would vote, I would choose "don't recurse if the scope folder is a symlink". I like an option "ask users not to create such symlinks", but if I and @farewell7117 faced this twice in a week, there would be also other users with the same problem. Also, just thought about another use case. What would happen if somebody would use |
Using For example, test the path against the regex As far as I know on NPM registry and yarnpkg, So by this logic yarn should assume packages starting with |
|
I just got hit by this bug as well - and more precisely the user of a package I maintain https://github.com/Rush/link-module-alias. The reporter had all of their source files removed by yarn as indicated here Rush/link-module-alias#3 :-( In my opinion In order to reproduce:
|
I haven't had time to work on this yet, but would be interested to merge a fix - would someone be interested to contribute it? I could review and merge it in time for the next release 🙂 |
FYI, just got a report that a user lost several hours of work: |
@arcanis What will be the solution? I use symlinks to avoid relative paths in require calls.
After |
This issue also manifests when using yarn 1.16.0 in combination with lerna, which is a monorepo manager that symlinks packages to each other. yarn panics with Incidentally, |
I'm currently hard at work on the v2 trunk, but if you open a PR that implements option 2 ("don't recurse if the scope folder is a symlink") I'd be happy to review it 🙂 |
What about regular symlinks like I said before? I don't use |
I'm in this same situation -- I need to have a symlink in my |
Same here, I would like to add a package during development and keep the symlinks in node_modules, rather than having to recreate them if |
same here... |
same here |
I also have a very specific needs that neither yarn nor npm can satisfy at the moment, I'm developing framework that heavily relies on a lot of path resolution, webpack, React and others; So there's a lot of module and path resolution work in there. So I finally decided to test my framework (locally test) as if it were installed from npm and was located in the 'node_modules', so I just |
Closing as you can use the https://yarnpkg.com/features/protocols#whats-the-difference-between-link-and-portal |
I have some symlinks in
node_modules
that come from another custom tool. Yarn likes to blow them away:The text was updated successfully, but these errors were encountered: