81–90 of 486 posts
I just tried to install yarn and ran it to against a relatively large React application. What's interesting is that it found an incompatible module and could not proceed, whilst npm works fine. The article states that running `yarn` is the same as `npm install`, which doesn't look like the case. At that point, I'm curious what are the differences.
This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…
And a shrewd move by FB: to not announce their new registry on the same day.
This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…
I find it strange that the time isn't invested in already existing projects. But at least it's a move away from NPM. I think the most problems I had with JavaScript develompent in the last 2 years came from NPM.
While Yarn sounds like a nice wrapper with extra stuff. I want to ask if this collaboration couldn't happen with the NPM team?
npm's been involved since the early days, they wrote up a blog post here: http://blog.npmjs.org/post/151660845210/hello-yarn
You shouldn't check in node_modules. You should use a shrinkwrap file to indicating the specific sub-dependency versions you're using.
This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…
Multiple versions may sound like it's useful, but it's almost always a bad idea. Cargo doesn't allow it either. The problem isn't really fundamental. Bundler makes almost all the right choices already. Its major disadvantage is that it only works for Ruby.
Yarn does offer a `--flat` option that enforces the highlander rule, and I'm hopeful that the existence of this option will nudge the ecosystem towards an appreciation for fewer semver-major bumps and more ecosystem-wide effort to enable whole apps to work with `--flat` mode.
Plz send halp!
This is a huge leap forward for the JavaScript community—probably more than many people will realize right away. I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package m…
Multiple versions may sound like it's useful, but it's almost always a bad idea. Cargo doesn't allow it either. The problem isn't really fundamental. Bundler makes almost all the right choices already. Its major disadvantage is that it only works for Ruby.