@cpojer
Nothing here yet.
Nothing here yet.
No blogs yet.
We were scrambling a little bit to get ready for the open source release and the global command didn't get as much attention as we would have liked to give it. If you want to help contribute making it better, please open RFCs or send a pull request :) See https://github.com/yarnpkg/rfcs
We think it is really important to stay compatible with the entire JS ecosystem and there is little value in changing how dependencies are stored in package.json . However, we add additional things in other files, like the yarn.lock lockfile. That way your project will stay compatible with npm but when you use Yarn you get additional guarantees like installing known versions of packages that will work well with your project. It is unlikely that the structure of node_modules will change fundamentally because it'll have to stay compatible with node.js. It is entirely possible that the node module resolution algorithm may change one day, but that would affect npm and Yarn both the same.
Since both of the projects are solving fundamentally different problems, using different languages, we thought it was ok to name the project Yarn. I also answered above why we chose this name in the first place. When people talk about the hadoop project I heard most of them call it "Apache Yarn" which I think is enough of a distinction.
We realized that npm install is actually doing two different things: Install dependencies from package.json Add new dependencies to your project. If you forget to --save a dependency, you even end up with something in your project that isn't actually part of your package.json . Since Yarn was a completely new project we decided to rethink this approach and be more sensible. With Yarn: yarn install will install your dependencies based on the lockfile or write a lockfile if none exists. yarn add <package> will add a new dependency and add it to the lockfile and package.json file. We do not support installing packages that won't be part of your manifest file.