It is important to take account of the Yarn’s use of npm registry to provide even those developers who don’t work at a larger scale and helps to improve their performance. According to Sebastian McKenzie (software engineer) and Tom Occhino (engineering manager) at Facebook, a lot of internal infrastructure has been developed by the company around npm. Practices overtime made it clear that it didn’t worked really well so Facebook had to make major modifications.
The reason why npm does not have the ability to work with a bigger platform such as Facebook is that it has some major issues when it comes to dealing with company’s workflow. Yarn works enhances the local file caching and it has the ability to parallelize few of its operations. For latest modules, this actually spurs up the process. With Facebook, npm worked in a different way. It slowed down the company’s incessant integration workflow and the engineers had to install the “npm install” command manually. But in the insulated continuous integration and sandboxed environments, it didn’t work.
For the DevOps workflow, Facebook’s engineers were in a need of a consistent and reliable system and npm was non deterministic. In order to create reliable file structure across the machines, Yarn applies lock files and deterministic install algorithm.
There was also a security concern that arouse with npm, the manager allows developers to execute other codes which were required as a part of the install process. Yarn does not have that feature at all.
According to McKenzie, our team wanted to fix npm according to its own requirements because most features of the npm client didn’t worked well with Facebook. The features that were demanded by company’s team would not have been accepted by the npm community. The commercial unit that is behind the npm project is very well aware of this new development but there are no chances of a conflict as npm’s model revolves around registry and not the client.