8 thoughts on “yarn is deleting symlinks in node_modules that it doesn’t own”

  1. 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 node_modules if they have a package.json file. It won’t remove other non-package directories. It also just never cleans anything out of node_modules/.bin. Even npm prune doesn’t remove them.

    My personal opinion is that npm is incorrect. node_modules is the directory for the package manager to manage and no manual modifications should be made. I could be convinced otherwise though.

    @yarnpkg/core think this should be “closed / as designed” or a bug due to “npm compatibility”?

  2. You could, for instance, argue that npm would be correct in blowing away links or modules created by yarn workspaces since it doesn’t understand where they came from

    Yes it would, and probably should. If something doesn’t match the package manager expected output, it should be removed, otherwise the guarantee that yarn install is all that’s needed to get the exact same node_modules layout anywhere doesn’t hold.

    I’d hope that yarn would ignore both of these since it doesn’t understand them.

    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 dependencies.

    I don’t see why it should prune them

    They shouldn’t exist in the first place 🙂

  3. @arcanis — This goes back to my point that node owns node_modules, not the package manager, or at least not any one package manager. There’s absolutely no reason or benefit for yarn to aggressively prune things from this folder that it clearly doesn’t own since it has no way to create them.

    If you want to use custom protocols, then put them in another key than dependencies.

    Sure, except that yarn would still delete the files generated. Not having an escape hatch seems unnecessarily controlling.

  4. @rally25rs Not arguing with a point, that yarn install is cleaning all symlinks and directories inside node_modules, I have another problem here.

    If there is a symlink in a node_modules, that leads to an external directory, yarn install is following it and purging also an external content. Don’t you think, that behavior should be just unlinking a symlink instead of following it?

  6. 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 🙂

  7. 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 @.

  8. I’m in this same situation — I need to have a symlink in my node_modules and I don’t want yarn to delete it. My use case is I have a private copy of a package (pkgA) checked out as a git submodule in $TOP/pkgA; I’m working on both my main app and pkgA, so I want my build (and hot reload) to pick up changes in both. I’ve tried link: and workspaces but neither is helpful. Simple symlink node_modules/pkgA -> ./pkgA works perfectly, except that yarn deletes it! Could yarn just have an option for “known non-Yarn files in node_modules” that it just wouldn’t delete?

Comments are closed.