3 ms·

I haven't tried yarn but for those who did, what made you make the change?

tedeh 9y ago
Getting my node_modules corrupted several times (packages in package.json "randomly" going missing after installing new ones) requiring nuking node_modules and doing a fresh npm install. yarn has been a breeze to use so far, I'm loving the quick installs. Only nitpick is that I have to be inside of the working directory of the package.json when adding a new package, because yarn for some reason does not travel up the hierarchy and installs it in the same directory as the first encountered package.json, like npm does.
- jazoom 9y ago
  I keep getting bitten by this. It's really annoying.
leipert 9y ago
The killer feature for us was a more maintainable lock file. Back when we switched, it was way more readable than the npm-shrinkwrap.json and it is easier to fix merge conflicts in the yarn.lock. And if you are wondering: Why a lockfile? It has also been a game changer, everyone in my team has the same dependencies installs, dependencies do not suddenly break. (Anecdote: Before the switch some dependency of an dependency of an dependency overwrote some Array function, and broke our whole product. I was on vacation and had to fix this remotely, because it was kind of hard to debug). The only obstacles we ran into: 1) private registries did not work, but this has been fixed 2) yarn upgrade command behavior is sometimes funny, but this is going to be fixed soon: - https://github.com/yarnpkg/yarn/issues/3603 https://github.com/yarnpkg/yarn/issues/3603 - https://github.com/yarnpkg/rfcs/blob/master/text/0000-upgrade-command-consistency.md https://github.com/yarnpkg/rfcs/blob/master/text/0000-upgrad...
dguo 9y ago
1. A lock file that works well. My team spent countless hours dealing with strange npm shrinkwrap issues beforehand. The fact that it uses a lock file by default is also nice, since people don't have to remember to update it after adding or removing a package. 2. Deterministic installs (running install with the same lockfile will result in the exact same node_modules). With npm, we ran into issues that would somehow be fixed after deleting the node_modules directory and reinstalling everything. That worked far too often. 3. The offline mirror. This gave us a reasonable method for checking in our packages to our Git repo, meaning we could build our site without an internet connection. It basically fixed all of our issues with npm, saving us hours upon hours of time.

Getting my node_modules corrupted several times (packages in package.json "randomly" going missing after installing new ones) requiring nuking node_modules and doing a fresh npm install. yarn has been a breeze to use so far, I'm loving the quick installs. Only nitpick is that I have to be inside of the working directory of the package.json when adding a new package, because yarn for some reason does not travel up the hierarchy and installs it in the same directory as the first encountered package.json, like npm does.

jazoom 9y ago
I keep getting bitten by this. It's really annoying.

leipert 9y ago

The killer feature for us was a more maintainable lock file. Back when we switched, it was way more readable than the npm-shrinkwrap.json and it is easier to fix merge conflicts in the yarn.lock. And if you are wondering: Why a lockfile? It has also been a game changer, everyone in my team has the same dependencies installs, dependencies do not suddenly break. (Anecdote: Before the switch some dependency of an dependency of an dependency overwrote some Array function, and broke our whole product. I was on vacation and had to fix this remotely, because it was kind of hard to debug). The only obstacles we ran into: 1) private registries did not work, but this has been fixed 2) yarn upgrade command behavior is sometimes funny, but this is going to be fixed soon: - https://github.com/yarnpkg/yarn/issues/3603 https://github.com/yarnpkg/yarn/issues/3603 - https://github.com/yarnpkg/rfcs/blob/master/text/0000-upgrade-command-consistency.md https://github.com/yarnpkg/rfcs/blob/master/text/0000-upgrad...

dguo 9y ago

1. A lock file that works well. My team spent countless hours dealing with strange npm shrinkwrap issues beforehand. The fact that it uses a lock file by default is also nice, since people don't have to remember to update it after adding or removing a package. 2. Deterministic installs (running install with the same lockfile will result in the exact same node_modules). With npm, we ran into issues that would somehow be fixed after deleting the node_modules directory and reinstalling everything. That worked far too often. 3. The offline mirror. This gave us a reasonable method for checking in our packages to our Git repo, meaning we could build our site without an internet connection. It basically fixed all of our issues with npm, saving us hours upon hours of time.