5 ms·
Where to start. 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
by djhaskin987 8y ago
Where to start.
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 https://twitter.com/tdvorak/status/678613940746756096?s=19
[2]: https://xkcd.com/2140/ https://xkcd.com/2140/
[3]: https://link.medium.com/UVCo1GTaaW https://link.medium.com/UVCo1GTaaW
[4]: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html https://maven.apache.org/guides/introduction/introduction-to...
- gitgud 8y agoWell, broken builds are bad, but this can happen with any package management system right? Any open, easily updatable package management system will encounter these problems. Only testing and curation to ensure there's no broken builds will solve the broken builds issue. 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?
- ezekg 8y ago> especially given a community so willing to publish backwards incompatible changes come hell or high water 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 It really is ridiculous. And even with yarn, I still have multiple resolutions [1] in our package.json files due to breaking changes in patch versions without a fix. [0]: https://yarnpkg.com/lang/en/docs/cli/install/ https://yarnpkg.com/lang/en/docs/cli/install/ [1]: https://yarnpkg.com/lang/en/docs/selective-version-resolutions/ https://yarnpkg.com/lang/en/docs/selective-version-resolutio...