@zkochan missed your link. yes, i read it, pretty much when it was published. sorry if it doesn't change my stand.
i hope we can at least agree that issues like these are not just smoke - yarnpkg/yarn#2155 yarnpkg/yarn#1776 and similar thread on all package managers that have a lockfile. And most of them end up saying "yes, commit it, because it's going to make your life easier, but when you get merge conflicts, delete it and regenerate it" --- and on each one there's a person that gets the lightbulb "hold on.. if I have version A from 1995, version B from 2000, I want to merge them them, get a conflict, I delete and regenerate in 2005, doesn't it mean I will basically upgrade all sorts of sub-dependencies and loose the lock on them?"
shrinkwrap.yamlcurrently behaves when merged because I don't use it currently in a team. The company I am working at uses npm4.
foo@^1.0.0, foo@^1.1.0:in a line. Which can differ on merge, in
shrinkwrap.yamlalways blocks differ, not lines
package.jsonthere r some modules with
*version. If the module doesn't exist in npm repo, the module won't be installed, as well as other modules from deps list. Ember CLI requires to have
*as a value for addons development. npm handles it fine and installs the rest of modules.
./node_modules/.bin/pnpm link supi/