[koolhaas]

Thanks for the response. And thank you for clarifying that there is a larger ecosystem of package repositories, and that Deno does not give preferential treatment to any. In theory npm can do the same, but of course there is official support and community gravitational pull around a single service.

I agree there is nothing fundamentally less secure in general, but what you don’t get is being able to standardize around security for dev account protection, policies around immutability, DNS stuff, and some other centralized security measures. Neither are bullet proof, but there are some things you can’t protect against with random URLs.

I’d argue URLs are fine until you get massive use of a single package and it weaves itself into a complex dependency tree across multiple other critical projects. Then you worry about the what if’s.

[wperron]

> I’d argue URLs are fine until you get massive use of a single package and it weaves itself into a complex dependency tree across multiple other critical projects. Then you worry about the what if’s.

This is already an issue with npm. My personal take on this is that at that point that dependency should be vendored as much as possible but obviously it's hard to fight the existing inertia on this one. Also worth noting that the [std lib][1] is an attempt at a pragmatic solution to the problem where these foundational packages that are seemingly used by every framework out there essentially converges to the standard lib. I agree it's not perfect at the moment but it's a start.

[1]: https://deno.land/std