Comment by wperron | Hacker News Reader

Comment by wperron | Hacker News Reader

Parent Full thread

deno.land/x is _not_ a central registry. It's something we maintain as a convenience to the community, but we actually go to great lengths to make sure it doesn't receive preferential treatment from the CLI. Importing modules from nest.land, skypack.dev, esm.sh or jspm.io is common in the ecosystem and is something we're looking to keep encouraging.

It's also pretty easy to vendor in your dependencies so that they don't move between the time you commit and the time your server starts. We also support lock files so you don't _have_ to vendor your deps too. Versioning is up to the server you import from, but typically you'd put version in the URL somewhere (ideally a pinned version).

Security-wise, There are other articles out there that detail this but it's not fundamentally less secure than importing from npm as you're still pulling a JavaScript file from the internet in both cases. The cool thing here with URLs is that it's pretty easy to audit and create an allowlist of known-good and trusted servers to import from in your org.

As for vulnerability reporting & patching; I think we're still lacking a good vulnerability database, that much is true, but fixing deeply integrated deps that have vulnerabilities is pretty easy using import maps really.

> It's also pretty easy to vendor in your dependencies

It's not the first time I see this claim in this discussion. Describe "easy".

In the case of the much-hated npm, or yarn, it's as easy as:

   npm/yarn install package

This will pull both the package and all its dependencies. It will create a lock file and will essentially lock the version. There are additional ways to specify the exact versions, and version ranges for packages and dependencies.

Additionally, it's quite trivial to make npm/yarn to pull not from npm, but from, say, a private package registry that only has vetted and audited packages.

So. Given that "it's easy to vendor in your dependencies", how will all this look in Deno?

We already know that even such a simple thing as lockfiles is, multiple manual steps with awkward parameters to the cli that people shouldn't forget [1]. This is... not easy.

[1] https://deno.land/manual/linking_to_external_code/integrity_...

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.

> 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

Reply on news.ycombinator.com