And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).
I hate to break it to you but dependency management has been a massive issue in golang until the devs formally adopted go mod.
Only Google seemed okay with checking in their dependencies to version control. Everyone else was doing crazy hacks like https://labix.org/gopkg.in
You will ask, what about adding the OS to your SCM too, yeh why not have the full software stack. But you can generally draw a line between strong abstraction layers: Hardware | Kernel | OS | runtime | your app. Some modules do have strong abstraction layers, but others are just pure functions which you could just as well copy into your own repo.
I haven't seen anyone commit vendor and not complain about it. But now you finally don't have to commit vendor for reproducible builds. All you need is a module proxy. The "all you need" is not really meant seriously of course.
And I personally prefer to not commit vendor and complain about it.
This is starting to look like a case of being different just so you can say you're different.
In my opinion this is Deno’s biggest selling point.
Could you elaborate on this? Is it that Deno is against the whole 'small packages that do one thing well' principle and instead in favor of complete libaries? How exactly would it dissuade me from installing hundreds of dependencies?
> The idea there is to include only what you need deliberately and it manage it as a remotely written extension of your application.
I have a node app, in which I deliberately only included the dependencies I need. The package.json lists exactly 8 dependencies. However, the node_modules folder already has 97 dependencies installed into it. The reason of course is that these are dependencies of dependencies of dependencies of dependencies.
Wouldn't Deno have this same issue? Are the dependencies also distributed in compiled form as a single file akin to windows DLLs?
How is that not "decentralisation"
And if you are importing single files from a remote url, I would question your sanity.
yep, that's basically the same. deno has the benefit of using the es module system like it is implemented in browsers.
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.
Imports from URL would allow me to know exactly what I'm getting.
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?
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.
Do you manually install a list of libraries provided by the author's readme?
1 - not wipe the cache folder at each build? It's easy and secure. Oh and your build will be faster.
2 - use a cached mirror of the deps you use? It's like 10min to put in place and is already used in companies that care about security and availability anyway.
3 - you have https://deno.land/x if you want to put all your eggs in the same npm basket
I still don't understand how this is better than NPM, and how Deno solves the horrible dependency management of Node, but maybe if I actually build something with Deno I'll get some answers.
> [With NPM] the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web.
Subjective.
> Centralized currency exchanges and arbitration is not in line with the ideals of the web! - Cryptocurrency
Nek minute. Besides, let's get real here; they will just end up centralized on GitHub. How exactly is that situation much different than npm or any other language ecosystems library directory being mirror-able?
git does not require Github to be online to work, nor relies on Github existence for its functionality.