Personally, I think NPM is a crazy, mental concept. As a Go developer (so mostly server-side work) I can't fathom the amount of deps that are pulled from NPM when I'm working with or watching a JS code base being used. I assume server-side NodeJS code bases are the same their front end cousins in terms of deps pulled(?)
I feel like it's clickbait, not worth reading, for these points:
1. Even if the argument is valid, the points made in this article have been expressed, shared, (whined about?) probably 9+ times in my own reading. It's really time to move on.
2. There is nothing inherently wrong with using small/simple modules. Once you start to reuse code in many projects, the value becomes clear. Some are juicy and complex, some are eye-bleeding simple. It's better than copying and pasting code around folders. Use org modules/private modules and the problem is solved.
I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues.
No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved.
Jeez that reads harsh. Apologies, it's late.
Clickbait is specifically a sensationalist headline that is above content with little to no actual journalistic value.
The title of the post is a quite accurate summary of the entire text in a few words, so I think it totally serves it's purpose as a title.
It matters little that the arguments have been brought up before, that only makes the article stale but not clickbait in of itself.
Now, if there was a lack of an actual, journalistic article below the headline I might be more inclined to agree it being clickbait.
All good, friend.
> ... It's really time to move on.
But is it? I fear that if this is a genuine issue, why would I want to move on from it? Essentially npm is enabling people to build bridges in the same way steel is helping people to build actual bridges. If there was a flaw in some steel production process, I wouldn't ignore it. People could suffer.
Extreme(?) examples a side, if it's an issue, why not aim to solve it? This seems to pop up a lot, so perhaps it's time for a (long-term) solution?
> Use org modules/private modules and the problem is solved.
Yes! This is where I personally see the long-term solution: pick your top-level deps, (permanently) cache them locally and validate them, then implement/use them. Only update the cache when you're confident the remote, official copy has been changed in a manner that's safe for you and or your users.
> I absolutely believe that npm is ripe for *potential abuse, although I have yet to have any issues.
How do you know you've not had any issues? If I was attacking you via some sort of "side channel" attack, like breaching and injecting bad code into an NPM module I know you're using, how would you know it's happened?
Are you using a CI/CD process? The changes are high that you are and therefore unless you've version/commit pinning, it's likely you're blind to those deps being updated during your build process, enabling me to perform said "side channel" attack.
> No one has time for Breitbart-esque fearmongering, or the regurgitation of stale points while an ample selection of real world problems exist to be solved.
If it's being regurgitated so much, perhaps it is a "real world" problem to be solved.
I don't think most people deny that it's a problem or that it needs to be fixed. But completely blown out of proportion with Breitbart-esque fear-mongering is something that needs to stop. People still talk about "leftpad" as if it wasn't fixed the same day, sometimes as if it were never fixed, sometimes even as if it isn't even possible to write software in NodeJS. I haven't seen a fair and factual comparison chart of npm vs pip vs crate vs composer, and I'm calling BS that the majority of this "concern" is anything more than trendy JavaScript-Hate until I see one.
The fearmongering does get on your nerves but I think it's undeniable that npm's version conflict resolution (i.e. "have your cake and eat it too") has led to more complex dependency trees than e.g. in Python where the need to avoid version conflicts creates an inherent aversion to adding too many dependencies. However I think it's also undeniable that this has in turn enabled a lot of growth and innovation.
WTH is Breitbart? Bart Simpsons's evil twin?
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.
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?
How are we to take that seriously?
Ever heard of not invented here syndrome?
npm has problems, I won't deny it... but its not unique to javascript developers (which your comments about come off as extremely offensive), and its difficult to take seriously given the lack of any meaningful alternative offered.
Its just a rant... and people love to hate on javascript... so... click bait.
(also submitted what 3 times previously? And here I was hoping it would just wash away without triggering a js rant this time too..)
But it's not about npm as a technology, but about the mentality around how it's used. It enables laziness.
Pardon my ignorance but last time I checked Go deps where a mess: you list deps as github repos always pointing to latest master. The concept of version control did not exist. I have written some go and write a lot of js. I'd choose npm over that everyday.
> I assume server-side NodeJS code bases are the same their front end cousins in terms of deps pulled(?)
Most frontend code bases use actually very little dependencies, the big blob of (dev) dependencies are in the build pipeline: you need to transpile, compile, optimize, bundle, etc. the codebase. You only need those if you want to compile the frontend.
In order to run go code you need the compiler which is a binary of at least 100 megs. You can of course compile manually on your machine and push an executable, but you can do the same with a frontend (if your NODE_ENV is production npm will not download all compile deps).
Time to check again.
Breaking API compatibility is something that happens very rarely (I think I had to fix up applications of mine about once a year because some dependency changed), most packages with active development are very mature.
Additionally we have tools like dep and (soon) vgo that allow you to vendor and pin certain dependencies at certain versions (you can do it manually too, /vendor/ is where go looks first for any dependencies so you can replicate "dep init" by copying all dependency paths in your gopath into /vendor/)
There is also less "make a package for everything", packages tend to have much broader feature scope. is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package.
NPM does have an extra use case: Web development. Tree shaking in JS-land is still far from perfect and people don't want to (more like, are asked to) send as little as possible over the wire. So, different use cases, different trade-offs.
I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering.
Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step
You had already answered that on your previous sentence :)
> go can do tree shaking and will not include packages in the binary that aren't used
Again, different languages, different trade-offs. JS isn't statically compiled. This is a much harder problem to solve for JS. I'm talking from personal experience when I say that it still isn't completely solved (requires ES2015 module syntax and has many assumptions). Even Go has hard-time optimizing-away some code because of its limited type system.
>You had already answered that on your previous sentence :)
Yes but NPM/Yarn should be capable of atleast dropping packages that can be statically proven to not be imported. That means if a package imports require("xy-" + variable) then you'll have to be clever but if a package consists only of static imports then you can shake a lot.
I also don't like how all people became "X developers". We are software developers. I don't think anyone who can code JS would have difficulty switching to Go or vice versa (unless you are a mostly non-technical person, probably from marketing, who learned just enough jQuery, something which I also respect - I never learned just-enough marketing).
The tooling is irrelevant. It's about how it's all brought together and used.
> As a Go developer
Pot, meet kettle.