←back to thread

Deno 2.4

(deno.com)
133 points hackandthink | 5 comments | | HN request time: 0.203s | source
1. eranation ◴[] No.44488684[source]
I believe the reason Deno is not more widely used in production environments is the lack of a standardized vulnerability database (other than using 100% npm compatibility which will take many popular deno packages out of scope). The issue is that there is no real centralized package manager (by design) which makes it challenging. Was there any development in that direction?
replies(2): >>44489094 #>>44492946 #
2. TheDong ◴[] No.44489094[source]
> I believe the reason Deno is not more widely used in production environments is the lack of a standardized vulnerability database

If this were a real blocker, then C/C++ wouldn't be used in production either, since both just lean on the language-agnostic CVE/GHSA/etc databases for any relevant vulnerabilities there... and C also heavily encourages just vendoring in entire files from the internet with no way to track down versions.

Anyway, doesn't "deno.lock" exist, and anyone who cares can opt-in to that, and use the versions in there to check vulnerability databases?

3. simantel ◴[] No.44492946[source]
Wouldn't this also be a problem for Go, which just imports from URLs (mostly GitHub) as well?
replies(2): >>44493185 #>>44494857 #
4. ◴[] No.44493185[source]
5. jitl ◴[] No.44494857[source]
The go imports use a Google-owned proxy for resolution which has a vulnerability facility. All golang package installs use the Google-owned proxy unless you set GOPROXY=direct when running go commands.

https://arc.net/l/quote/arrozgok