Running yarn install after removing a dep manually doesn't remove it from the yarn.lock

[jamiebuilds]

Do you want to request a feature or report a bug? Bug

What is the current behavior?

Removing a dep manually and then running yarn install doesn't remove it from the yarn.lock

If the current behavior is a bug, please provide the steps to reproduce.

yarn init --yes
yarn add object-assign sorted-object
# manually update package.json to remove object-assign
yarn install
cat yarn.lock

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


object-assign@^4.1.1:
  version "4.1.1"
  resolved object-assign-4.1.1.tgz#2109adc7965887cfc05cbbd442cac8bfbb360863

sorted-object@^2.0.1:
  version "2.0.1"
  resolved sorted-object-2.0.1.tgz#7d631f4bd3a798a24af1dffcfbfe83337a5df5fc

What is the expected behavior?

It should remove the unused items from the yarn.lock

Please mention your node.js, yarn and operating system version.

• Yarn: 0.191
• Node: 7.0.0
• OS: macOS

[MaartenStaa]

I think yarn install should always install dependencies as listed in the lock file, i.e. the current behaviour "feels" right to me. If your dependencies change, isn't yarn upgrade what you want?

However, PHP's Composer does display a warning when running the install command, and the lock file is outdated compared to the composer.json file. Maybe that would be a better option.

[AlexLandau]

When the package.json has been updated to include a new dependency or a new version of a dependency, yarn install modifies the yarn.lock file to suit the package.json. It seems strange that it makes these changes for some types of modifications, but not others.

I think of yarn upgrade as a more heavyweight operation, as it bumps a potentially large number of dependency versions and doesn't just clean up unused entries of the lockfile. (Though maybe my perception here is skewed due to my background working with Java, where bumping versions of dependencies is seen as a bigger deal.)

[AlexLandau]

It looks like yarn --force has the behavior I want in this case, i.e. it will update the lockfile to remove unneeded dependencies in situations where yarn alone would not.

[seansfkelley]

This behavior is especially confusing in light of what yarn add does when you're in this state.

Starting with the original repro:

yarn init --yes
yarn add object-assign sorted-object
# manually update package.json to remove object-assign
yarn install
cat yarn.lock

Then do:

yarn add leftpad
cat yarn.lock

Which yields:

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


leftpad@^0.0.0:
  version "0.0.0"
  resolved "https://artifactory.palantir.build:443/artifactory/api/npm/all-npm/leftpad/-/leftpad-0.0.0.tgz#020c9ad0787216ba0f30d79d479b4b355d7d39c3"

sorted-object@^2.0.1:
  version "2.0.1"
  resolved "https://artifactory.palantir.build:443/artifactory/api/npm/all-npm/sorted-object/-/sorted-object-2.0.1.tgz#7d631f4bd3a798a24af1dffcfbfe83337a5df5fc"

add does this cleanup, but install won't, which feels weird since add is now removing things from a disjoint part of the dependencies than what I explicitly asked it to interact with; i.e., leftpad and object-assign are entirely unrelated, but yet this lockfile cleaning happens and removes object-assign anyway. It's also weird that the --force flag would be the way to get this behavior, since the docs suggest it's more of a "don't use the cache" than a "rewrite the lockfile" (though I did use this workaround to solve my problem).

I had understood install to mean "make node_modules reflect package.json exactly" rather than "make node_modules the merger of package.json and yarn.lock", though the docs don't really touch on this subtlety of the command one way or the other.

[cpxPratik]

yarn install works in strange way, when adding new package in package.json, it adds those those package and update yarn.lock accordingly. But when removing, it doesn't update lock file accordingly but the removed package is removed from node_modules directory.

Yarn should have behaviour similar to composer. yarn install should install dependencies based on yarn.lock file. If there is no yarn.lock file then it should invoke yarn upgrade and make lock file. When we update package.json, we should not be able to reflect changes in package.json with yarn install but only with yarn upgrade. And warn when there is dependencies mismatch between lock file and json file.

[klouskingsley]

you should use yarn remove xx

[pauldraper]

I think yarn install should always install dependencies as listed in the lock file, i.e. the current behaviour "feels" right to me.

I think so too. However, as others have pointed out, it was decided in #570 that yarn install would by default recreate yarn.lock to match the list in package.json. The problem is that it is inconsistent, i.e. it only works that way for half changes to the package list.

you should use yarn remove xx

I like using a editor for editing source files (and package.json is a source file) -- not cat, yarn, etc. -- and then using build/packaging tools to apply those updates.

Worse, if I've already removed a bunch of packages, I have to go add them back, and then run yarn remove, or else it won't work. Plus, yarn remove reorders my package.json

[gihrig]

you should use yarn remove xx

This command will remove xx from package.json but it's left in node_modules and yarn.lock. So that's not a solution.

yarn -v 1.7.0
node -v 10.6.0
OS X 10.11.6

This behavior feels buggy to me.

[kshutkin]

When using npm I used to run npm prune after removing something from package.json. With yarn it says The prune command isn't necessary. `yarn install` will prune extraneous packages. And yarn install does not work in this case.

[DSil]

When I delete something manually, usually yarn install --force updates my yarn.lock without touching my package.json.
I am not sure if it can have further consequences, but I am usually able to achieve the intended result here.

[paul-soporan]

Closing as fixed in v2.

https://yarnpkg.com/getting-started/migration