News for hackers. Stuff that matters.
Re:Deno 1.0 by ricardobeat on Wednesday May 13, 2020 @08:43PM (#23173765)
You answered your own question. Nothing stops you from using a mirror with deno too.
Re:Deno 1.0 by bgdam on Wednesday May 13, 2020 @08:51PM (#23173829)
Which again brings me back to something I'm still not understanding - How is Deno's package management better than NPM if it is extremely similar to NPM, but slightly less secure?

I'm only asking because lots of people seem to be loving this new dependency management, so I'm pretty sure I'm missing something here.

Re:Deno 1.0 by kjksf on Wednesday May 13, 2020 @10:13PM (#23174454)
We need to distinguish between npm, the service (https://www.npmjs.com/) and npm, the tool.

Deno has the functionality of npm, the tool, built-in.

The difference is that like Go, Deno imports the code directly from the source repository.

In practice it's going to be github.com (but can be gitlab or any code hosting that you, the author of Deno module, use).

NPM is a un-necessary layer that both Go and Deno has removed.

It's better because it's simpler for everyone involved.

In Go, I don't need to "publish" my library. People can just import the latest version or, if they want reproducibility, an explicit git revision. Compared to Go, publishing to npm is just unnecessary busy work.

I've seen JavaScript libraries where every other commit is related to publishing a new version to npm, littering the commit history.

In Go there's no need for package.json, which mostly replicates the information that was lost when publishing to npm (who's the author? what's the license? where's the actual source repository?).

As to this being insecure: we have over 10 years of experience in Go ecosystem that shows that in practice it works just fine.

Re:Deno 1.0 by gavinray on Thursday May 14, 2020 @01:18AM (#23175601)
How do you list the dependency libraries if you don't have a package.json?

Do you manually install a list of libraries provided by the author's readme?

Re:Deno 1.0 by afiori on Thursday May 14, 2020 @03:24AM (#23176473)
The simplest approach is to either import anything anywhere, or have a local module that import external dependencies and then have your code import them via that local module.
Re:Deno 1.0 by Epskampie on Thursday May 14, 2020 @01:56AM (#23175863)
The dependencies are imported in the source code of the package.
Re:Deno 1.0 by moogly on Saturday May 16, 2020 @08:18AM (#23202789)
NPM, the tool, has had the feature to be able to install directly from GitHub instead of npmjs.org for many many years as well. No one really used it unless as a workaround for unpublished fixes because it has no other tangible benefits.
Re:Deno 1.0 by mrkurt on Wednesday May 13, 2020 @08:53PM (#23173845)
I like it because it's simpler. I know what happens when I import from a URL. I'd have a hard time whiteboarding exactly what happens when I `npm install`.
Re:Deno 1.0 by searchableguy on Wednesday May 13, 2020 @09:16PM (#23174029)
What happens?
Re:Deno 1.0 by sakarisson on Thursday May 14, 2020 @01:33AM (#23175707)
My least favorite thing about importing from NPM is that I don't actually know what I'm importing. Sure, there might be a GitHub repository, but code is uploaded to NPM separately, and it is often minified. A malicious library owner could relatively easily inject some code before minifying, while still maintaining a clean-looking repo alongside the package.

Imports from URL would allow me to know exactly what I'm getting.

Re:Deno 1.0 by _630w on Thursday May 14, 2020 @02:48AM (#23176219)
install from the repo then?

You can install a specific version from git via yarn/npm.

How do you trust a url more without reading the code?

What's going to stop deno ecosystem from putting minified js files on cdns and import them?

Re:Deno 1.0 by keb_ on Wednesday May 13, 2020 @09:09PM (#23173968)
It's decentralized.