4 ms·

> Why do you need to audit dependencies you don't use? Don't use `is-odd`, nobody is forcing you too. So should I audit every dependency of every single packag

by __sr__ 8y ago

> Why do you need to audit dependencies you don't use? Don't use `is-odd`, nobody is forcing you too. So should I audit every dependency of every single package I use? Every time I upgrade every single package? Nobody is forcing me to use anything, but I can't very well use the ecosystem if I avoid every single package either. > The existence of garbage doesn't mean the system is broken, or that the ecosystem is "chaotic and insecure". That is exactly what it means. If you allow anything and everything with no quality checks, you gain "quantity" but lose out on "quality". > It means that it's inclusive, and anyone can make a package, no matter how terrible you might think it is. Would you be comfortable someone who can't drive being your chauffeur? Or perhaps someone with know experience with civil engineering building your bridges? Or perhaps someone with no knowledge of finance being your banker? All in the name of inclusiveness, of course. Why is it any different for software? The things we are talking about are the integral components of The Web -- something we relay on more than we care to admit -- it is not some toy. Be as inclusive as you want, but not at the cost of quality -- at least not for something that affects the entire world. And everyone can make a package is like saying everyone can build a bridge. But would you use it?

Klathmon 8y ago
>So should I audit every dependency of every single package I use? Yes, if you feel you need to. Like with every other part of software, you need to draw a line at where you will "implicitly trust". For many they only "review" the direct dependency and rely on that dependency to not include garbage. For others that means they want to audit every single line of code in their codebase. For others still they want to audit OS packages, OS code, hell even the hardware. Luckily the npm ecosystem gives you tools to help with your auditing if you want to use them. Tools that can graph the dependencies, tools that can scan for poor quality dependencies, tools that can lock versions down so when you update you only have to review code that has changed, tools to override dependencies that you don't like with your own code even if it's transitively required by someone else. >If you allow anything and everything with no quality checks, you gain "quantity" but lose out on "quality". This is such an elitist point of view. Just because everyone is allowed to make a package doesn't suddenly mean all packages are worse quality. Just like with the web, the lack of a gatekeeper lets the ecosystem flourish. >Would you be comfortable someone who can't drive being your chauffeur? Or perhaps someone with know experience with civil engineering building your bridges? Or perhaps someone with no knowledge of finance being your banker? No, No, and No. But you are able to decide for yourself if you want to. If you really want a "walled garden" (i know that's a loaded term, but i just mean a place where someone needs to decide if a package is worthy of inclusion or not), then you can still get one by only using a subset of the available packages. There are companies out there that audit npm packages, there are many that have a whitelist of what is allowed to be used. You can just stick to those and pretend that the rest don't exist, and the rest of us can freely choose from all of them if we want. A walled garden will always have a subset of a free and open ecosystem, if you feel it's necessary, feel free to try and make your own package manager that enforces a level of quality on the packages. I'm sure many would enjoy it, but don't try to get rid of all packages in other systems that you don't feel adhere to your standards. And absolutely don't claim that all js packages are bad because bad ones exist.

by __sr__ 8y ago

Klathmon 8y ago

>So should I audit every dependency of every single package I use? Yes, if you feel you need to. Like with every other part of software, you need to draw a line at where you will "implicitly trust". For many they only "review" the direct dependency and rely on that dependency to not include garbage. For others that means they want to audit every single line of code in their codebase. For others still they want to audit OS packages, OS code, hell even the hardware. Luckily the npm ecosystem gives you tools to help with your auditing if you want to use them. Tools that can graph the dependencies, tools that can scan for poor quality dependencies, tools that can lock versions down so when you update you only have to review code that has changed, tools to override dependencies that you don't like with your own code even if it's transitively required by someone else. >If you allow anything and everything with no quality checks, you gain "quantity" but lose out on "quality". This is such an elitist point of view. Just because everyone is allowed to make a package doesn't suddenly mean all packages are worse quality. Just like with the web, the lack of a gatekeeper lets the ecosystem flourish. >Would you be comfortable someone who can't drive being your chauffeur? Or perhaps someone with know experience with civil engineering building your bridges? Or perhaps someone with no knowledge of finance being your banker? No, No, and No. But you are able to decide for yourself if you want to. If you really want a "walled garden" (i know that's a loaded term, but i just mean a place where someone needs to decide if a package is worthy of inclusion or not), then you can still get one by only using a subset of the available packages. There are companies out there that audit npm packages, there are many that have a whitelist of what is allowed to be used. You can just stick to those and pretend that the rest don't exist, and the rest of us can freely choose from all of them if we want. A walled garden will always have a subset of a free and open ecosystem, if you feel it's necessary, feel free to try and make your own package manager that enforces a level of quality on the packages. I'm sure many would enjoy it, but don't try to get rid of all packages in other systems that you don't feel adhere to your standards. And absolutely don't claim that all js packages are bad because bad ones exist.