Of course, yet it starts with awareness. Would love if the extensions would also show the number of child's, number of authors, if it has an active community, t

Of course, yet it starts with awareness. Would love if the extensions would also show the number of child's, number of authors, if it has an active community, the license, and more info that you use to make the decision. Then again, we would also need the licenses of the children, their activity etc. It's a zoo out there these days. Packages that are licensed MIT have children that are GPL licensed. One package dragging in 200 more, leading to famous left-shift debacles and maintenance hell. Meanwhile support periods are being lowered to 1-3 years, even on big projects. Another issue we run into is different libraries using different packages which depend on the same package down the line but a different version which do not work together. So yes, I wholeheartedly agree that one must think before taking in a dependency. Especially if you just took it because a nice stackoverflow.com answer said so and you are going to use 1% of the package. Our build already immediately flags SOUP that is brought in but not assessed yet. We had it failing for a while but that was too much of a barrier for engineers. CI/CD scans for vulnerabilities using tools like whitesource or blackduck. Tools like fortify and sonarqube run amongst many more. All leading to better code, definitely. Yet, at a cost. Haven't found the best set of 'rules' yet what to allow and what a practical choice is today. Keeping velocity at the right quality.