3 ms·
Forget 10000000 packages. Many languages often make use of 10s of packages. If I have several projects, each with around 10 packages, and no automated way to ju
by tolmasky 6y ago
Forget 10000000 packages. Many languages often make use of 10s of packages. If I have several projects, each with around 10 packages, and no automated way to just check if all my projects’ respective dependencies have security updates that could be applied, it seems to go against the stated security goal.
Separately I’m not sure what is enforcing this “small dependency graph” aside from making it hard to import things I guess. I wouldn’t be surprised if you end up with the normal behavior of people coming up with cool things and other people importing them.
- austincheney 6y ago> and no automated way to just check if all my projects’ respective dependencies have security updates Dependency management is a major cornerstone of any infosec program. There is more to that than just auto-installing a new dependency version. > I’m not sure what is enforcing this “small dependency graph” Because a large dependency graph is slow, insecure, and fragile.
- tolmasky 6y ago> Dependency management is a major cornerstone of any infosec program. There is more to that than just auto-installing a new dependency version. We seem to agree? I said check. It’s very useful to have something tell you what’s out of date and what the updates are. > Because a large dependency graph is slow, insecure, and fragile. I asked “what”, not “why”. What is enforcing this idea you have of how Deno will be used? I feel like you want it to not be used with lots of dependencies, thus aren’t accounting for how to handle them. However, just because that’s the desired way to use it doesn’t mean it will be used that way. Lots of dependencies may end up still becoming the norm, at which point you’ll wish you would have more clearly defined how it should be done instead of letting the first third party solution win (as ended up happening with npm).