Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"
With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map[1], the browser will take care of download/cache them all.
Exactly. And it's quite easy to do.
> With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map
I was waiting for the inevitable just.
- Just set up your own CDN.
- Just upload a plain js file there (where do I get those files from?)
- Just point to dependencies using a feature that, quote "is not a W3C Standard nor is it on the W3C Standards Track"
- And then the browser... record scratch who said anything about a browser?
Where do you et these lockfiles files from?
> This is no different to module loading in Node.
This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936
> If you don’t trust your registry, you should not be loading code from it!
So you immediately pinpointed the difference: with Node I can run my own registry and easily set up npm/yarn to never load packages from anywhere else. Deno loads code from random urls.
I don't know about any lock files but the `version` it locked via the import url E.G import R from 'https://deno.land/x/rambda@v7.0.1'
for example to add bootstrap to a site you import like this
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstr..." integrity="sha384-ka7Sk0Gln4gmtz2MlQnikT1wXgYsOg+OMhuP+IlRH9sENBO0LRn5q+8nbTov4+1p" crossorigin="anonymous"></script>
which is exactly the same as deno's "loads random files from random URLs"
Deno is not a browser.
> for example to add bootstrap to a site you import like this
I know how to import a file in a browser. However, Deno is not a browser. The whole subthread is about managing dependencies, which Deno fails at, and its proponents come up with the most ridiculous things to justify it.
You are so wrong. If you would have done maybe 3 minutes of Googling you would know we support import maps, which allow you to arbitrary rewrite specifiers, even deep inside of the module graph.
At dev time, you generate a lock file of the hashes of your dependencies. You commit this file to your code repository.
When getting dependencies, the hash of the downloaded dependency is compared to the one in the lockfile.
So. At dev time. You download random files from random urls via Deno.
Compared to: At dev time you download files from a trusted repository. https://news.ycombinator.com/item?id=29871936
If you use a lockfile, downloading a package from NPM or directly using a random URL is conceptually the same, since they are both untrusted sources. Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.
It's not. But it's rather trivial to run your own registry, and many (most?) companies do exactly that.
> It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities.
That's why, again, many companies run their own registries, and don't download random files from the internet.
> Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.
And to generate that lockfile... you need to first download a random file from the internet. Got you.
Which is why we support a) import maps which allow you to rewrite all URLs however you want, and b) HTTP_PROXY, which allows you to intercept all HTTP traffic (also letting you rewrite all specifiers).
I don't know if you have ever worked on a Go project, but it has a very similar registry proxy situation as Deno. It works well.
the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it
Your argument is that npm is more trustworthy than another random registry, this is likely true but also a matter of opinion.
Yes. Have you've ever heard of running your own registry? It' quite easy to do and most companies do it prcisely because they want to a) keep published versions and b) prevent things like colors/fake.js
Literally no one who promotes Deno has yet shown how to do the same with Deno beyond "yeah, you check in all your node_modules dependencies into Git".
There is. For starters, I can run my company's registry and make sure all npm packages are downloaded from there since resolution mechanism for npm/yarn is well known.
How do I tell deno to download <random-url> from my own registry?
Looking at how deno "solves" this I can't stop laughing [1]
--- start quote ---
In Deno there is no concept of a package manager as external modules are imported directly into local modules. This raises the question of how to manage remote dependencies without a package manager. In big projects with many dependencies it will become cumbersome and time consuming to update modules if they are all imported individually into individual modules.
The standard practice for solving this problem in Deno is to create a deps.ts file. All required remote dependencies are referenced in this file and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies...
With all dependencies centralized in deps.ts, managing these becomes easier.
--- end quote ---
Are you for real?