This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up with this ecosystem?
Yarn – A new package manager for JavaScript
131–140 of 486 posts
Re: Yarn – A new package manager for JavaScript
#132So, as a casual user of node... Should I switch? I don't see any immediate benefits.
Re: Yarn – A new package manager for JavaScript
#133This 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.
With tiny modular utilities this is very much necessity - and not a bad idea if the different versions are being used in different contexts.
For instance, when using gemified javascript libraries with bundler it is painful to upgrade to a different version of a javascript library for the user facing site while letting the backend admin interface continue using an older one for compatibility with other dependencies.
Re: Yarn – A new package manager for JavaScript
#134Earlier quoted context omitted.
Have you guys approached the ridiculous folder nesting situation? E.g. breaking out of the current/broken node_modules structure?
There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.
fwiw npm really needs an `exec` command like bundler has (ie `npm exec bin-cmd`).
"$(npm bin)/bin-cmd" is getting really old
Re: Yarn – A new package manager for JavaScript
#135Earlier quoted context omitted.
Have you guys approached the ridiculous folder nesting situation? E.g. breaking out of the current/broken node_modules structure?
There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.
fwiw npm really needs an `exec` command like bundler has (ie `npm exec bin-cmd`).
"$(npm bin)/bin-cmd" is getting really old
Re: Yarn – A new package manager for JavaScript
#136This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…
JavaScript is the new BASIC and every millennial wants to populate his/her Github portfolio for Silicon Valley interviews.
Re: Yarn – A new package manager for JavaScript
#137This 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 loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once This is due to the way that Ruby includes code, where it's available globally, vs Node where code is scoped to the including module. I'm not sure how Ruby could support multiple versions with changes to the language and/or RubyGems
Yes, that's why I said it was a Ruby limitation, not a Bundler limitation.
Re: Yarn – A new package manager for JavaScript
#138Just installed it and ran it on a largish project ( https://www.bugreplay.com ), the parallel downloads really sped things up and outputted some great diagnostic info about problematic dependencies. BugReplay is a webapp for recording webapp bugs, so having some confidence that our dependency chain isn't introducing our own bugs would be awesome :)
Re: Yarn – A new package manager for JavaScript
#139This may come off as a troll, but it's an honest question. I'm not a javascript guy. It's not a language I deal with at all. Why on God's green earth does it need as much tooling as it seems to have? Are people really making projects with dozens (hundreds? more?) of dependent libraries? Are there aspects of the language or runtime that reward multiple layers of configuration management? In short, what the hell is up…
A very limited standard library with no native (well, just approved but not ratified) support for importing/libraries. Coupled with inconsistent implementations and you end up need more layers of abstraction.
Re: Yarn – A new package manager for JavaScript
#140Earlier quoted context omitted.
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.
Yarn isn't a replacement for npm itself. It's a client that can read/write to npm, and other registries such as Bower.
npm = node package manager = CLI tool which Yarn replaces.
npmjs.com = package repo which Yarn can use.
at least as far as I can tell