3 ms·

I wouldn't say it's similar to front-end JS. With front-end dev you're dealing with programming logic as well as the chaotic world of browsers, DOMs, 'standard

I wouldn't say it's similar to front-end JS. With front-end dev you're dealing with programming logic as well as the chaotic world of browsers, DOMs, 'standards' (or the lack thereof) and other quirks which manifests itself in complex ways. Server side JS is more foucsed in what it does though you still get the dependency trees. Sure, you may consider npm crazy; consider what it's providing to the developer ecosystem. Conversely to your opinion, coming from C#, Java, Node... I would consider `go get` just as puzzling, as well as community members providing multiple package managers (with go dep only now being worked on). There are definitely good reasons for those no doubt, just as there are good reasons for npm's solution.

movedx 9y ago
I see npm has "crazy, mental" because of HOW it's used, not for its sheer existence as a "thing." Technically it's a good solution. Very solid. For me, it's more the mentality around just accepting a dependency tree made up of thousands of modules, with little to no validation or vetting, versus doing something to make sure what's being pulled is safe and even worth it. With a Go application, I would 'dep ensure' to vendor what I needed and then actually look at what was pulled. Once I know what's been brought down and I'm happy with the code, I "off line" (cache) those dependencies and never update them again unless I need to (security, bugs or big features.) Also now that they're vetted and off line, I can reuse them over and over in confidence. Thoughts?