- Large dependency trees
- 100's of Mb of code for hello world react projects
These seem like superficial problems, from what I can tell the system encourages:
- Software reuse (maybe too much)
- Bundling source with the package (good for verification)
- Easy to contribute to the ecosystem
- Fast resolution of modules
Do people just hate NPM because it's JavaScript?
In the past they have ripped off some ones copyrighted code when it was a dependancy for everything[1]. After that they then deleted other peoples packages claming copyright infringement because there partner wanted the package name[2]
A lot of people moved to the faster alternative yarn, this caused the NPM developers to rain in their bull.
Their past actions and how they wield power are a demonstration that they should not have it, their attitude is one rule for us and another for everyone else.
[1] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [2] https://kodfabrik.com/journal/i-ve-just-liberated-my-modules...
If a developer is the authority on a package, they should be able to do what they want right? Not sure why this is a bad thing, people can fork the project if they don't agree with the changes. Or just use previous versions.
What's the alternative? A single authoritarian political agenda?
> A lot of people moved to the faster alternative yarn, this caused the NPM developers to rain in their bull.
Yarn is just another CLI tool, it doesn't have its own packages and connects to the NPM repository.
Also, it's now extremely hard to remove or change a version of a package on NPM...
Yes creating a non authoritarian fork is the only effective alternative, which is why I mention yarn. Yarn might not solve all of the problems with NPM but it showed the NPM developers that people would build alternatives if NPM pushed them to it.
In response NPM has lifted a lot of yarns features and improved its speed. Despite not being perfect it was at least affective enough as an alternative for NPM to notice and fear.
The Left Pad mentioned above is a prime example - do you really need a dependency for that? Start adding nested dependencies and well it's simply a mess!
Rather, it shows that dependencies should really be immutable, at least versions of dependencies anyway. It seems it's no longer possible to remove a package from npm, you're only able to deprecate it. Which means Left Pad cannot happen again, in this way.
Software reuse is an important part of progressing technology and I think it should be encouraged... or at least made easy...
foo % 2 === 0
?
What about another module to call the first one and invert the return?
Development based around npm modules is a joke
What's the alternative? Allow only packages with code over 100 lines? 1000 lines?
Packages are an excellent way to share code, regardless of complexity...
The alternative is allowing packages with more than a single function. It's NPM and the javascript development culture which is enforcing the arbitrary limit of "no more than a single function per package."
Sure, you can do trivial things in a package, but that calls into question the usefulness of enforcing that level of granularity versus having libraries of related functions, shallower dependency trees and less fragility.
I suppose it's similar to the Unix philosophy, "do one thing and do it well". Also don't forget that people can repackage these fine grained tools into a single library package too.
Why does a function to check if a number is even need its own namespace, and a dependency on another namespace which tests if it's a number at all, and a third to check if it's odd? What's the benefit to this?
>I suppose it's similar to the Unix philosophy, "do one thing and do it well"
Any philosophy can be taken too far.
The benefit is modularity, separation of concerns and versioning but in this case it's ridiculous...
Any philosophy can be taken too far
That should be printed on my office wall!
However a malicious actor could still upload a broken minor version that most node projects would try to automatically resolve to, and thus break...
Your exception is not limited to malicious actors as even ligitmate packages like uglifyjs have had to do this. The NPM developers themselves have no problem deleting packages which would result in the same problems. They solved their problem by pushing it onto the rest of us.
Probably the two biggest arguments are bloat[1] and broken builds. Both seem to be caused by an obsession with the culture of "never reinvent the wheel"[2] which can be stifling and over-the-top, especially given a community so willing to publish backwards incompatible changes come hell or high water.
Both of these -- ease of publishing breaking versions and making libraries that are 11 lines long for the sake of not repeating them -- may have something to do with how npm manages dependencies. That is, it doesn't. You ask for a specific version of a library and you get it. Simple. You don't share this code version other libraries on the system. It sort of makes it easy to do the wrong thing, like backwards incompatible changes. For another example, this can cause problems when library B and A get results from calling library C and then communicate to each other using those results. You see, A uses C at a completely different version than B does. You end up with madness, and two copies of C (bloat).
Contrast this with maven. Yea, lots of small libraries, but maven only allows one version of a library to exist and doesn't tell you exactly which one it will pick [4]. This is horribly broken BUT encourages people to NOT write backwards incompatible stuff. It encourages a healthy community. Maven central doesn't receive nearly as much hate as npm in my experience
Then there's the crypto mining incident[3], but that could arguably have happened in one of several communities, really.
[1]: https://twitter.com/tdvorak/status/678613940746756096?s=19 [2]: https://xkcd.com/2140/ [3]: https://link.medium.com/UVCo1GTaaW [4]: https://maven.apache.org/guides/introduction/introduction-to...
This triggers me. I feel like I dealt with this issue almost on the daily (ok, ok -- weekly) until we fully moved to yarn and started freezing the lockfile [0] with:
yarn --frozen-lockfile
[0]: https://yarnpkg.com/lang/en/docs/cli/install/ [1]: https://yarnpkg.com/lang/en/docs/selective-version-resolutio...
As for bloat, software reuse should be at least an option, a better phrase is "Reinvent the wheel, only when necessary". You're example of Maven is a much less flexible system, although it promotes stable API's. The main problem with only allowing one version of a dependency in a project is that dependencies aren't isolated per package, which means with lots of libraries there's no way to guarantee that they all have the exact correct version of the library they need, which will inevitably result in weird errors.
The only reason libraries should use the exact same version is if they're communicating like you mentioned, soooo why not just explicitly state that dependency too then?