3 ms·
> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies.
by curry-castaway 8y ago
> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies.
Just trying to understand, is this a bad thing?
Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options.
Should Pika write and maintain its own custom CLI spinner animations? Are you saying the CLI spinners should be standardized in the next version of ECMAScript itself?
How is this worse than the same thing written in Python, for example? (I mainly use javascript, so maybe I haven't been exposed to the kinds of alternatives you're thinking about.)
- intertextuality 8y agoIt’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector that’s impossible to spot because it’s loaded as the 567th package in a dependency tree? The answer here is to have a strong stdlib where do you don’t need to pull in 3rd party packages all the time for trivial things, and not including a million small packages in every single project.
- curry-castaway 8y ago> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't seem to be a solution. If anything, more dependencies are a good sign because they imply that other people have spent more time and effort on a solution than anything you'll be able to hand-roll for single-use. It sounds like the root issue here is just dependency management. If our package managers were solving this issue well enough, there should be no practical difference between 2 big dependencies with significant functionality (and more code to review) or 20 tiny, easy-to-review dependencies.
- yardstick 8y agoFrom a security perspective, minimising dependencies is preferred. I have to review at least monthly all our dependencies for published vulnerabilities and new versions. We don’t allow automatic upgrading of packages/dependencies due to the risk of malicious code making it in (see https://www.npmjs.com/advisories https://www.npmjs.com/advisories for examples). Yeah there are companies that will help manage your vulnerability process but it’s still a lot of overhead and only grows as the number of dependencies grows. There’s also the whole left-pad mess from a few years back which shows you always need local archived copies of any dependencies you use.
- curry-castaway 8y ago> We don’t allow automatic upgrading of packages/dependencies due to the risk of malicious code That's a good idea, how do you do that? > you always need local archived copies of any dependencies you use. Are you committing your dependencies? Or using a package manager with caching?
- Torgo 8y ago>I have to review at least monthly all our dependencies for published vulnerabilities and new versions. Off-topic, but can you write about how you manage this without tons of manual work?
- intertextuality 8y agoThere is an enormous difference between 2 large packages and 20 small ones. I can see the main authors more clearly, and not have to worry about 20 different packages being compromised. Your statement makes no sense. More packages does not, in any way, shape, or form, correlate to “better quality”. The sole thing it shows is that the author pulled in more packages. That’s it. Whether it’s good or bad or secure or not secure is only determined by analysis. The author could easily have been super lazy and pulled in 18 small packages instead of writing small helper functions manually, etc. There is no defensible argument for more packages and bloat. None. As I said above, the core lib should focus on providing functionality so pulling in a fancy spinner library means you pull in ONE library, not 20.
- deleted 8y ago[deleted]
- jaabe 8y agoIt’s fine from a development perspective where the job is to make something work. It’s horrifying from an operations perspective where the job is to make sure everything works. Developers can afford to ignore looking into dependencies, operations need to make sure every dependency is functional and safe. If you write a piece of C# using the standard .Net library you can be fairly sure it’s safe and sound. If you write something using 2000 JS packages, you have to read through every one of them to be sure.
- ownagefool 8y agoI disagree that it's the job of a random ops person to ensure that a developers dependencies are sane. Putting the onus on the developer to do a good job with regards to secure development practices is an essential part of a wider system.